Issues connecting Odroid XU4 to Arbotix Pro

[NicoX]

After a lot of reading different posts of the forum finally I made my mind to buy a HROS-1 kit without servo. Big story short, I have a Modified Bioloid GP with most AX 18 servos that I was trying to walk. Since then one of my forum friend suggested to get HROS-1 kit as it uses affordable AX12/AX18 servos.

Before getting that I was a playing a lot with (and loorking a lot of KartEck's posts) Odroid XU4 and Teensy 3.6 to talk to different other electronics. I decided to give a try with XU4 to talk to Arbotix Pro to compile HROS-1 framework.
Here is the details I went through:

1. Used XU4 (not Q) and ported Linux Ubuntu 16.04.3 LTS (v3.1) / Linux Kernel LTS 4.14.5 as described here https://forum.odroid.com/viewtopic.p...214694#p214395

2. Installed HROS-1 on XU4. Needless to say I faced lot of issues so had to fix them all by following steps:

• I am using XU4 as headless but GUI was needed only to set it up with my home network. I took help of
  

   $ ifconfig 

• Update to latest OS
  

  $ sudo apt update
  $ sudo apt upgrade
  $ sudo apt dist-upgrade
  $ sudo apt install linux-image-xu3 
  $ sudo reboot   
  ## When you install “linux-image-xu3” package, you will meet a dialog box and you have to choose “No” to proceed the Kernel update. ##

• Installed Bluz for Linux
  

  $ sudo apt-get install libbluetooth-dev

• Installed jpeglib
  

   $ sudo apt-get install libjpeg-dev

• Installed HROS-1 framework
  

   $ git clone https://github.com/Interbotix/HROS1-Framework.git 

3. Performed servo checking by executing ./dxl_monitor (after make clean and make all). Here starts the pain....
I connected one of the 2 USB3 of XU4 to Arbotix Pro using the same 4pin cable and USB adapter as the Rus Pi video showing.
I am getting some ghostly response in terminal. Sometime the it is able to open the Arbotix Pro through port and mostly it fails. On failure the response printed is as:

Fail to open port
CM-730 is used by another program or do not have root privileges.
Failed to connect CM-730!
Terminated DXL Manager. 

4. If it gets a success the scan command is giving bizarre response. Either it says all servo failed to connect, though servos are all connected. Otherwise it finds a servo id which is not connected. I mean if I connect a servo id 3 to the bus removing others, it finds id 4, on next scan it finds 5 or sometimes 3 too. The failure response is as:

 Check ID:1(R_SHOULDER_PITCH)     ... FAIL
 Check ID:2(L_SHOULDER_PITCH)     ... FAIL
 Check ID:3(R_SHOULDER_ROLL)      ... OK
 Check ID:4(L_SHOULDER_ROLL)      ... FAIL
 Check ID:5(R_ELBOW)              ... FAIL
 Check ID:6(L_ELBOW)              ... OK
 Check ID:7(R_HIP_YAW)            ... FAIL
 Check ID:8(L_HIP_YAW)            ... FAIL
 Check ID:9(R_HIP_ROLL)           ... OK
 Check ID:10(L_HIP_ROLL)          ... FAIL
 Check ID:11(R_HIP_PITCH)         ... FAIL
 Check ID:12(L_HIP_PITCH)         ... OK
 Check ID:13(R_KNEE)              ... FAIL
 Check ID:14(L_KNEE)              ... FAIL
 Check ID:15(R_ANKLE_PITCH)       ... OK
 Check ID:16(L_ANKLE_PITCH)       ... FAIL
 Check ID:17(R_ANKLE_ROLL)        ... FAIL
 Check ID:18(L_ANKLE_ROLL)        ... OK
 Check ID:19(HEAD_PAN)            ... FAIL
 Check ID:20(HEAD_TILT)           ... FAIL
 Check ID:25(UNKNOWN)             ... OK
 Check ID:200(ARBOTIX_PRO)        ... FAIL
 Check ID:202(UNKNOWN)            ... OK 

I am not sure what is the issue behind all these, some pointers will be really helpful.
I think I have to update the firmware of Arbotix pro. Not sure of it but found a thread of KurtEck http://forums.trossenrobotics.com/sh...to-Arbotix-Pro
So KurtEck, R3n33, Tician and all others, sending a help signal to you guys... )))))))))))))>>>>)))>>>>))

Side note: I do have a Teensy 3.6 would it be faster in communication to AX12/AX18 rather than Arbotix Pro? I will try to use the HROS-1 code base as base.

Regards
NicoX

[KurtEck]

It has been awhile since I played with the HR-OS1... Actually I am meaning to list it for sale as well as a few Hexapods to make room for some other stuff...

But back to your issues.

Ability for Odroid to talk to Arbotix-pro (/dev/ttyUSB0)

a) Permissions: In order to talk to the Arbotix, I believe that the /dev/ttyUSB0 device will be created in the dialup group.
So I would make sure you are a member of the dialup group something like: sudo adduser odroid dialout

(assuming your user odroid)..

Now getting it to properly talk. There were several conversations about some of earlier threads. But basically the communications are timing out, when trying to do read operations.

So, to have better luck with this, I had/have a version of the HROS1 framework that does a real logical flush output (tcdrain), which helped. Not sure if this made it back into main code base. I know I have versions of similar code for ROS hexapod and my RPI project that does this, but only when talking to FTDI as when talking to other controllers like USB2AX or Teensy, this could slow things down as I don't think their lower level drivers had support for DRAIN so it just uses a long timeout...

I always prefer Teensy over the Arbotix-Pro, for many reasons... Like you don't need to spend another $50 for hardware to reprogram them... Some of my later playing around with HROS1 with Arbotix-Pro, I had a setup where instead of communicating through USB, I had them talking through Serial port. If I remember correctly I believe you needed level shifter between the two as Arbotix was probably 3.3v and Odroid XU4 is 1.8V...

However the other thing about Arbotix-Pro and it's framework. The underlying code is assuming that it has an Accel and Gyro chip whoes values are stored as logical registers. Earlier I made a Teensy board that semi emulated this (like have a BNO055) chip on board, but then though I was neutering the capabilities of the IMU....

Anyway you might look at some of the things in some of the other forks of the framework. Like Renees (r3n33) or mine: https://github.com/KurtE/HROS1-Frame...-other-devttys

[MousKitos]

Same here : http://forums.trossenrobotics.com/sh...ade-on-my-RPI3


For the moment I not have one good solution. I found some ways but no result for the moment...


So today I use this Image : https://sourceforge.net/projects/hro...aspberry%20Pi/
And I DON'T make upgrade OS only sudo apt-get update to have dependencies when I install something else like RPI Cam .


I think the problem come from the new kernel...


I have here some link that maybe will help you if you want stay with the last (new) OS
https://raspberrypi.stackexchange.co...g-usb-problems
https://ludovicrousseau.blogspot.fr/...pberry-pi.html


Don't forget to post here if you find solution ;-)

[KurtEck]

I should mention, that I have not done as much with the RPI on the HROS1... Started off using the Edison, tried the RPI and then went to ODroid Xu3-lite and later XU4 with fan. Also these days I have not done anything with HROS1 for a long time...

Things that I did that helped for me or would try now if it were me...
a) Make sure that the calls to tcdrain were done as to force the output of the packet before it tries to get a response.
b) Find the timeouts and increase them.
c) If you have USB camera hooked up, try to put one of them on the USB3 port... Don't remember if the Odroid has different path too main internals for the USB3 vs the USB2 ports... Probably does not apply to RPI, which I think all funnel through one channel (don't remember if that is the right name for it)... But all USB and I believe networking on RPI all funnel through the same...

d) I punted using USB... That is I instead used a hardware Serial port on the ODroid (likewise could be for RPI), to talk to a USART on Arbotix Pro. I had a WIP version of the firmware for Arbotix-pro (https://github.com/KurtE/ArbotixPro/...usart2-talk-pc), that allowed me to talk to using the UARTS... I also updated the framework: https://github.com/KurtE/HROS1-Frame...-other-devttys
To allow this. The framework would look for the logical device: /dev/ttyDXL and if found would use it. This could be setup to be a link the the hardware serial port (either manually or using udev rules).

One main problem with d) is that in order to reprogram the Arbotix-Pro, you need to spend another $50 to get a programmer setup: http://www.trossenrobotics.com/pro-programming-kit . Also if you have one of the original HROS1 kits, the Arbotix Pro did not have easy to install programmer pins, so you might need to build a simple programmer adapter... I think is in the Arbotix-pro github... But again warning, last time I touched any of this was two years ago!

With RPI and maybe Odroid, I know with at least hexapod, that some had better luck when they installed a real time kernel... So you might search for that thread.

[NicoX]

First of all thanks a lot KartEck for responding back. Because of some people like you, we get to know the proper direction.
Back to the steps I followed after going through the forum updates.

Ability for Odroid to talk to Arbotix-pro (/dev/ttyUSB0)
a) Permissions: In order to talk to the Arbotix, I believe that the /dev/ttyUSB0 device will be created in the dialup group.
So I would make sure you are a member of the dialup group something like: sudo adduser odroid dialout
(assuming your user odroid)..

Ans: Checked in XU4 terminal ie.

 $ sudo adduser odroid dialout

#The user `odroid' is already a member of `dialout'.
So I am in diaout group and you are correct in guessing my user is odroid. So that is not an issue.

Now getting it to properly talk. There were several conversations about some of earlier threads. But basically the communications are timing out, when trying to do read operations.
So, to have better luck with this, I had/have a version of the HROS1 framework that does a real logical flush output (tcdrain), which helped.
....
Anyway you might look at some of the things in some of the other forks of the framework. Like Renees (r3n33) or mine: https://github.com/KurtE/HROS1-Frame...-other-devttys

Ans:
I saw your changes by comparing the main repo with yours. It looks nice the tcdrain part. So I decided to give a try after cloning your repo on XU4. Compiled darwin.a OK and compiled dxl_monitor.a OK.
Next I connected a 4 pin wire to Arbotix Pro parallel port next to micro USB port and through the USB breakout board with 4 pin female port added that to one of the 2 USB3 ports of XU4.
Unfortunately my noobness might not figure out some more so the result I received was somewhat improved but similar.
The scan on ./dxl_monitor is confused with the id value of AX12. When I am connecting a servo with ID 19 alone it mostly says 19 OK but some times a re scan says it is ID 20 / 21.
And with multiple AX12/AX18 servos connected it mostly fails to recognize the proper id for a servo.

[ID:200(ARBOTIX_PRO)] scan




 Check ID:1(R_SHOULDER_PITCH)     ... FAIL
 Check ID:2(L_SHOULDER_PITCH)     ... FAIL
 Check ID:3(R_SHOULDER_ROLL)      ... FAIL
 Check ID:4(L_SHOULDER_ROLL)      ... FAIL
 Check ID:5(R_ELBOW)              ... FAIL
 Check ID:6(L_ELBOW)              ... FAIL
 Check ID:7(R_HIP_YAW)            ... FAIL
 Check ID:8(L_HIP_YAW)            ... FAIL
 Check ID:9(R_HIP_ROLL)           ... FAIL
 Check ID:10(L_HIP_ROLL)          ... FAIL
 Check ID:11(R_HIP_PITCH)         ... FAIL
 Check ID:12(L_HIP_PITCH)         ... FAIL
 Check ID:13(R_KNEE)              ... FAIL
 Check ID:14(L_KNEE)              ... FAIL
 Check ID:15(R_ANKLE_PITCH)       ... FAIL
 Check ID:16(L_ANKLE_PITCH)       ... FAIL
 Check ID:17(R_ANKLE_ROLL)        ... FAIL
 Check ID:18(L_ANKLE_ROLL)        ... FAIL
 Check ID:19(HEAD_PAN)            ... OK
 Check ID:20(HEAD_TILT)           ... FAIL
 Check ID:200(ARBOTIX_PRO)        ... FAIL
 Check ID:202(UNKNOWN)            ... OK


On Fail
[ID:200(ARBOTIX_PRO)] scan




 Check ID:1(R_SHOULDER_PITCH)     ... FAIL
 Check ID:2(L_SHOULDER_PITCH)     ... FAIL
 Check ID:3(R_SHOULDER_ROLL)      ... FAIL
 Check ID:4(L_SHOULDER_ROLL)      ... FAIL
 Check ID:5(R_ELBOW)              ... FAIL
 Check ID:6(L_ELBOW)              ... FAIL
 Check ID:7(R_HIP_YAW)            ... FAIL
 Check ID:8(L_HIP_YAW)            ... FAIL
 Check ID:9(R_HIP_ROLL)           ... FAIL
 Check ID:10(L_HIP_ROLL)          ... FAIL
 Check ID:11(R_HIP_PITCH)         ... FAIL
 Check ID:12(L_HIP_PITCH)         ... FAIL
 Check ID:13(R_KNEE)              ... FAIL
 Check ID:14(L_KNEE)              ... FAIL
 Check ID:15(R_ANKLE_PITCH)       ... FAIL
 Check ID:16(L_ANKLE_PITCH)       ... FAIL
 Check ID:17(R_ANKLE_ROLL)        ... FAIL
 Check ID:18(L_ANKLE_ROLL)        ... FAIL
 Check ID:19(HEAD_PAN)            ... FAIL
 Check ID:20(HEAD_TILT)           ... FAIL
 Check ID:21(UNKNOWN)             ... OK
 Check ID:200(ARBOTIX_PRO)        ... OK

And if I try to talk to that servo it fails for sure.

[ID:200(ARBOTIX_PRO)] id 19
 Invalid ID(19)!
[ID:200(ARBOTIX_PRO)]

a) Make sure that the calls to tcdrain were done as to force the output of the packet before it tries to get a response.
b) Find the timeouts and increase them.

Ans:
a> I hape this has been taken care of in @KartEck's HROS1-Framework repo, right?
b> How to increase timeouts, or has been taken care of in @KartEck's HROS1-Framework repo?

d) I punted using USB... That is I instead used a hardware Serial port on the ODroid (likewise could be for RPI), to talk to a USART on Arbotix Pro. I had a WIP version of the firmware for Arbotix-pro (https://github.com/KurtE/ArbotixPro/...usart2-talk-pc), that allowed me to talk to using the UARTS... I also updated the framework: https://github.com/KurtE/HROS1-Frame...-other-devttys
To allow this. The framework would look for the logical device: /dev/ttyDXL and if found would use it. This could be setup to be a link the the hardware serial port (either manually or using udev rules).


One main problem with d) is that in order to reprogram the Arbotix-Pro, you need to spend another $50 to get a programmer setup: http://www.trossenrobotics.com/pro-programming-kit . Also if you have one of the original HROS1 kits, the Arbotix Pro did not have easy to install programmer pins, so you might need to build a simple programmer adapter... I think is in the Arbotix-pro github... But again warning, last time I touched any of this was two years ago!


With RPI and maybe Odroid, I know with at least hexapod, that some had better luck when they installed a real time kernel... So you might search for that thread.

Ans: d> Do you @KartEck think that I need to get the programmer and re flash Arbotix Pro with your frimwire?
In this case I have to order it and will take some time to reach for sure.
By this time as you also prefer Teensy 3.6 can I make use of it?
I must confess that I am little noob in porting Arbotix Or Teensy with XU4. But definitely wanted to give any possible try.
I feel Teensy 3.6 will be faster in communicating with Dynamixel AX12/18 than Arbotix Pro.
Any step by step guide for Odroid XU4/ Teensy/ AX12 will be superb help.


Again Thanks KurtEck for your time.

NicoX

[NicoX]

Don't forget to post here if you find solution ;-)

Thanks for your interest in the discussion, I will post here my step by step updates. Feel free to lat us know if you find any success.

[KurtEck]

Again sorry, I am not really much help here. I have not looked at this stuff for maybe 2-3 years.

For TImeouts - I think it is the function:

void LinuxArbotixPro::SetPacketTimeout(int lenPacket)
{
    m_PacketStartTime = GetCurrentTime();
    m_PacketWaitTime = m_ByteTransferTime * (double)lenPacket + 5.0;
}

Which I think should give plenty of time, but can try to increase and see if it helps...

Some other generic suggestions:


For things like this, I use a logic analyzer to look at what and when something is being sent on the DXL chain. So I almost always have one of my Saleae logic analyzers sitting on my desk... Sure helps with guessing.

---

You might email support and see if they know of any issue. I know that had to replace a few of these boards.

---

Try to make sure all of the servos are actually working and have proper IDs... There have been times when servos reset their id to #1, and if you have multiple servos with same ID, it can cause interesting issues... I have a tendency to try a few different things, like:

run my own servo test program: I have my own collection of linux code with lots of detritus up at:
github.com/kurte/Raspberry_pi (first linux was RPI so the name...). There is a somewhat quick and dirty test program: AX12_Test, that runs my own code to talk to the servos... It uses very primitive command lines, like: s<cr> will do a scan for all servos on the AX buss... Again I often use this program to verify that I have all of the servos... If things start to error out, I start off unplugging most of the servos, maybe leave just one legs servos and see if it finds those... If So then add another leg, if not try removing that leg and plug in another. If that works, then go back to one that failed. Try removing servos down the chain to see if you can get things to work...

Try a different servo controller: Having something like an USB2AX to plug into your Odroid, is a nice simple setup. You then run a bioloid jumper wire from it to a powered AX Bus hub where you apply the power. Now can you talk to all of the servos?

Teensy: are nice boards, but you do need to do something to make them work with Dynamixel servos. You need someway to do the half duplex protocol. My code has two different ways of doing it:
a) Use half duplex support of the uart - You connect the TX pin of the UART to the DXL buss (like the USB2AX), and my BioloidSerial code knows to set it up and to switch directions.

b) you use an external Buffer chip(s), which take another IO pins (direction), which then you setup the RX/TX pins to the buffer along with direction pin. It is wired up the same way one would do an RS485 setup to the Teensy and then the SerialX code knows when to change directions... Again BioloidSerial library knows about this...

BUT: As I mentioned, the Arbotix-Pro also has other functionality like some IMU like support, which the HROS1 framework makes use of. So would need to either somehow emulate this or to update the framework to use an external IMU.

Earlier I was playing with my own Teensy 3.2 Arbotix-Pro like board that has an IMU on it. I played around with a couple of them that could take a BNO055 or a LSM9DS1 chip on it
Example one that looked like:

But then got distracted, and started playing around with some different versions, where instead of being sized to be like the Arbotix Pro, was instead a hat that could plug into RPI connector (or Odroid using level shifter board) or UP board...

Then started playing with T3.6... Again some different versions of it... But in these cases I dropped adding room on the board for IMU... As again still think external IMU that the Linux code can directly talk to is maybe better.

Or if I decided I wanted some basic IMU... I can add one of the ones from https://www.tindie.com/stores/onehorse/
Where he has some that solder onto the bottom of the Teensy boards...

---------------------
Power: I also double check power issues. Are you trying this with Wall wart or battery? If Wall wart how much current does it supply? My HROS1 kit came with an 10 amp version.

Again sorry not sure if anything here can help or not...

[NicoX]

Again sorry, I am not really much help here. I have not looked at this stuff for maybe 2-3 years.

For TImeouts - I think it is the function:

void LinuxArbotixPro::SetPacketTimeout(int lenPacket)
{
    m_PacketStartTime = GetCurrentTime();
    m_PacketWaitTime = m_ByteTransferTime * (double)lenPacket + 5.0;
}

Which I think should give plenty of time, but can try to increase and see if it helps...

Thanks a lot KurtEck it actually worked.
Here is the test result after changing code as

void LinuxArbotixPro::SetPacketTimeout(int lenPacket) {
    m_PacketStartTime = GetCurrentTime();
    m_PacketWaitTime = m_ByteTransferTime * (double)lenPacket + 20.0; //5.0 -> 20.0
}

$ sudo ./dxl_monitor
[Dynamixel Monitor for DARwIn v1.00]
/dev/ttyUSB0 open success!Set 1000000.0bps success!
Check ID:1(R_SHOULDER_PITCH)     ... OK 
Check ID:2(L_SHOULDER_PITCH)     ... OK 
Check ID:3(R_SHOULDER_ROLL)      ... OK 
Check ID:4(L_SHOULDER_ROLL)      ... OK 
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)           ... FAIL    #Please note id 19 was physically disconnected so it should fail# 
Check ID:21(UNKNOWN)             ... OK 
Check ID:22(UNKNOWN)             ... OK 
Check ID:23(UNKNOWN)             ... OK 
Check ID:24(UNKNOWN)             ... OK 
Check ID:200(ARBOTIX_PRO)        ... OK

[ID:200(ARBOTIX_PRO)] off 
Dynamixel power off

[ID:200(ARBOTIX_PRO)] on 
Dynamixel power on

[ID:200(ARBOTIX_PRO)] id 1
[ID:1(R_SHOULDER_PITCH)] d

[EEPROM AREA] 
MODEL_NUMBER            (R) [000]:   18 (L:0x12 H:0x00) 
VERSION                 (R) [002]:   26 
ID                     (R/W)[003]:    1 
BAUD_RATE              (R/W)[004]:    1 
RETURN_DELAY_TIME      (R/W)[005]:    0
 CW_ANGLE_LIMIT         (R/W)[006]:    0 (L:0x00 H:0x00) 
CCW_ANGLE_LIMIT        (R/W)[008]: 1023 (L:0xFF H:0x03) 
HIGH_LIMIT_TEMPERATURE (R/W)[011]:   75 
LOW_LIMIT_VOLTAGE      (R/W)[012]:   60 
HIGH_LIMIT_VOLTAGE     (R/W)[013]:  140 
MAX_TORQUE             (R/W)[014]: 1023 (L:0xFF H:0x03) 
RETURN_LEVEL           (R/W)[016]:    2 
ALARM_LED              (R/W)[017]:   36 
ALARM_SHUTDOWN         (R/W)[018]:   36

[RAM AREA] 
TORQUE_ENABLE          (R/W)[024]:    0 
LED                    (R/W)[025]:    0 
CW_COMPLIANCE_MARGIN   (R/W)[026]:    1 
CCW_COMPLIANCE_MARGIN  (R/W)[027]:    1 
CW_COMPLIANCE_SLOPE    (R/W)[028]:   32 
CCW_COMPLIANCE_SLOPE   (R/W)[029]:   32 
GOAL_POSITION          (R/W)[030]:  439 (L:0xB7 H:0x01) 
MOVING_SPEED           (R/W)[032]:    0 (L:0x00 H:0x00) 
TORQUE_LIMIT           (R/W)[034]: 1023 (L:0xFF H:0x03) 
PRESENT_POSITION       (R/W)[036]:  472 (L:0xD8 H:0x01) 
PRESENT_SPEED          (R/W)[038]:    0 (L:0x00 H:0x00) 
PRESENT_LOAD           (R/W)[040]:  983 (L:0xD7 H:0x03) 
PRESENT_VOLTAGE        (R/W)[042]:  118 
PRESENT_TEMPERATURE    (R/W)[043]:   34 
REGISTERED_INSTRUC     (R/W)[044]:    0 
MOVING                 (R/W)[046]:    0 
LOCK                   (R/W)[047]:    0 
PUNCH                  (R/W)[048]:   32 (L:0x20 H:0x00)
[ID:1(R_SHOULDER_PITCH)] 

Bad part is it is delaying a bit. So response is coming after certain time after.
Some question came on my mind:
1> Do you think if I update the firmware of Arbotix Pro will this come to a part where we can have best communications?
2> I am also a fan of Teensy 3.6 and I may wish to do some modifications in HROS code base. My question is may I get some superb less latency in communication, if I use Teensy 3.6 with an IMU and connect it with Odroid XU4 as following link?
http://openrobot.cl/en/
http://openrobot.cl/wp-content/uploa...-schematic.jpg
3> Lastly which Saleae logic analyzers will you advice for me?
I do not carry any logic analyser but I do have a DSO (OWON SDS-8202V Deep Memory Digital Storage Oscilloscope 200 MHz) that I use to measure signals .

Regards
NicoX

[KurtEck]

1) Not sure what you are asking? Update firmware of Arbotix-Pro. Yes I had better speeds when I bypassed using USB to communicate and instead used TTL Usart to talk. But needless to say that is not a supported configuration. Although not sure there is much support for any configuration of the Arbotix Pro...
Some things to look at here include:
a) Have you updated your servos to set the return delay to 0? This helps speed things up a little... Also don't remember if the Arbotix has this logical setting as well... Should try to make sure these delays are minimized.

b) I don't remember if there is something you can/should do to allow real time priority threads on the Odroid and/or if you need to use SUDO to get it?

c) and again level shifting of voltages...

2) Teensy 3.6 - I do very much like them... For many reasons including they are supported... I have not worried about doing DMA transfers for talking to the servos. I have been able to use normal Usarts to talk easily at 2mbs, I think I tried 3 and 4ish also. In these cases you should use Serial1 or Serial2 as these clock faster more hardware buffer...

As for the schematic you showed, that is not the way that I would do it, but maybe should work... There are others up here like @tician or @jwatee, who do electronics designs a lot better than I do... But I don't see using the 3.3v to 5v TTL converter than go to the buffer like output to do RX/TX direction switching separate.

I have done this a few different ways:
a) use two small chips like 74HC1G125GV/74LVC16126GV (port numbers might not be exact here), but have two different buffers that do the conversion of 3.v to 5v. The differences of the two is the OE pin. One is OE the other is not OE...

b) One larger chip like: SN74LS241DW - Which has an OE that handles some of the conversions and a NOT OE which handles others, which you connect both up to same TTL line...

c) Simply connect up the 3.3v to DXL... I used to do this all the time with T3.2 and it worked fine most if not all of the time...

d) like c: except could add one bidirectional TTL level converter to output at 5v...

3> If you have a a Scope that works fine for you great, you may or may not need/want a logic analyzer... I do like the Saleae... Currently I have three of them, an older 16, the newer logic 8 (bought during their logical kickstarter) and later purchased a Logic Pro 8, which is what I use the majority of the time for higher speed things like SPI or USB... For simple UART stuff the others work great as well. Also you can make the others work well at faster SPI speed as well, if you configure the Teensy smartly. That is to set the clock speed to a speed that generates an SPI seed that is an even multiple of the speeds you can set with LA...

I don't appear to have any of my earlier logic analyzer outputs with the Arbotix-Pro... But I remember doing things like:
Setup Odroid to set an IO pin HIGH, do something like the register Read, and set the IO pin low when it returns with the completion. I then setup LA probes, on the IO pin, I know I tried to also setup a logic analyzer probe on the Uart data going to the Arbotix-PRO. Tried to connect to output of the FTDI output. Then also instrumented the Arbotix-Pro code to set IO pins when it received data... I also setup a LA probe on the DXL buss, so you could watch and see where the delays were coming in... But again this was 2-3 years ago so don't remember exact steps...

[NicoX]

I feel my Arbotix Pro has some issues. I dropped a note to support as well stating the problem and linking the thread too.
I was checking a Youtube video how to connect Arbotix Pro with PC via USB cable and id servos, here: https://www.youtube.com/watch?v=SCO_8nrldDE

I did the same, so now my PC is talking to Arbotix Pro (no Linux or XU4). It should happily detect all servos but please take a look at the screens I attached here. Seems like Arbotix Pro is being scanned by PC perfect, but getting all AX 12 Or AX 18 actuators were not picked by properly. So in the two screens you will see that scanned Dynamixel ids came out different. Some times success, some times not for the some Dyanmixel actuator with same id.

I think either the board needs a replacement Or the firmware needs to be updated. If could be a bug too.
Done anybody has similar experience out of blue??