Inconsistent Reading of XL430-W250-T Motors on Rasberry Pi

billy0305 · March 4, 2023, 12:40am

Use the following template to help create your post:

What model of servo are you using?
XL430-W250-T
Describe your control environment. This includes the controller or interface, and any power source.

3 XL430-W250-T motors connected to U2D2 power hub
2 of the motors are daisy chained to U2D2, one is plugged normally
U2D2 is connected to a Raspberry Pi running on Ubuntu 20.04 with ROS Noetic

Specify the operating mode for applicable models, and any firmware settings you are using.

Extended Position mode, reverse driving mode, with homing offset
Updated to most recent firmware

Include pictures if possible.

U2D2 overall connection

Daisy chained motor connection

Single motor connection

Inconsistent motor detection on Raspberry Pi

Include a full description of the issue.

Hello, I am trying to control 3 motors using dyanmixel sdk on raspberry pi with ubuntu 20.04. The problem is the the connection to the motors is really bad on rpi, which causes issues in sync read and writes to the motors. The connection seems to be fine when using Dynamixel Wizard; I was able to read and write to the motors. It’s just seems to be an issue when the U2D2 is connected to the Raspberry Pi. Any help will be much appreciated!

Currently, I’ve verified that:

the baudrate on the motors are 1 Mbps
all have unique IDs
return delay time to 0
latency_timer set to 1 ms

roboteer · March 6, 2023, 12:32am

Hello @billy0305

First, I must say that I have never used ROS, but I have used plain DXL SDK on RPi4B and XL430s in the past. So please consider my comments as “alternative” interpretations of your write-up:

You said that you could use Dynamixel Wizard (DW) OK, however using the U2D2 gave you troubles. What is unclear to me, is that for anyone to access the XL430 via DW, we need to use U2D2. Did you use DW on the RPi? Or did you use DW on a PC?
When I used straight DXL SDK on the RPi4B, ping() and scan() were never 100% reliable, so I never used them. If DW found them and accessed them OK, I did not care about what ping() and scan(0 told me. And for my case Sync Read Write had worked OK all the time. If for your case, Sync Read Write did not do their jobs properly, what were the symptoms? Random loss of packets? Sync Write worked OK, but Sync Read did not work? Or returned junk data?
From the pictures provided, I see some possible “silver” duct-taped areas on the longer DXL cables, is there any wire splicing beneath them?

billy0305 · March 6, 2023, 9:22pm

Thank you for the detailed response

I was using U2D2 for both RPi and PC (windows). I was using Dynamixel Wizard on PC to test whether reading and writing is working fine. I was using Dynamixel SDK on RPi to read and write to the motors.
I see. find_dynamixel package was using the scan() function. Both Sync Read Write was not working, both were returning [TxRxResult] There is no status packet!. Sometimes the read write works fine and able to control the arm.
The wires aren’t spliced, the tape was there just to organize the wires

I’ve attached the repo where I use the SDK to initialize and sync read write if it helps. The main part of the code is the init() where it initializes all the motor operating modes. Then it uses the update() callback function to read the motor angle and write the motor angle.

github.com

ih4kim/bexter-moveit/blob/main/dynamixel_hw_interface/src/dynamixel_hw_interface.cpp

#include <dynamixel_hw_interface/dynamixel_hw_interface.hpp>
#include <ros/console.h>
#include <cmath> 

#define ADDR_GOAL_POSITION      116
#define LEN_GOAL_POSITION       4
#define ADDR_PRESENT_POSITION   132
#define LEN_PRESENT_POSITION    4
#define ADDR_TORQUE_ENABLE      64
#define TORQUE_ENABLE           1
#define TORQUE_DISABLE          0
#define BIT_TO_RAD              0.087891f
#define ADDR_OPERATING_MODE     11
#define EXTENDED_POSITION       4
#define POSITION                3
#define MAX_POSITION            4294967295
#define M_PI                    3.14159265358979323846
#define ADDR_DRIVE_MODE         10
#define REVERSE_MODE            1
#define ANGLE_TRESHOLD          3.14159

This file has been truncated. show original

roboteer · March 7, 2023, 2:26am

From my own experiences in using the plain DXL SDK on RPi and Arduino, intermittent issues with Sync Write Read (especially Sync Read) are mostly likely coming from poor/loose (in a mechanical meaning) electrical connections somewhere: loose USB port, bad/poor quality USB cable, poor 3P DXL connections with/between DXLs. There are different approaches that you can try to figure out what is going on with your setup:

Dynamixel Wizard has a version that runs on Linux ( DYNAMIXEL Wizard 2.0 ). If DW runs OK on the RPi and accesses your DXLs consistently then may be there is an issue with ROS and/or DXL SDK, and the key finding is that there is nothing wrong with the physical connections of your setup. If there are physical connections issues, you should see intermittent problems with using DW and U2D2 when performing this test.
You can also do this second test in tandem with the first one, which is to run your ROS+DXL SDK Sync Write/Read code without powering the DXLs (i.e., disconnect the 12V power to the DXLs). Your code would still work fine, Goal Position and Present Position commands would still work fine, except the DXLs won’t go anywhere, they just stayed where they were set when you powered on your whole robot. Meaning that the embedded controller boards on each DXL are still powered on and working, and they should/would report the same initial Present Positions at all times to the RPi. If the PP values are reported fine, then this would indicate that DXLs when in actual motion may be shaking something loose intermittently. However, if you have intermittent problems when the DXLs are not moving, then this would be very bad news as it could mean ROS, or DXL SDK or even how RPi handles the data flow back and forth, way down in Linux kernel.

Another thing that I noticed in your source code is the 4294967295 value used for MAX_POSITION. Is this parameter used for checking when setting Goal Positions?

The ROBOTIS e-manual reported the following values as MIN and MAX limits for GP for the XL-430 when in extended position control mode (XL430-W250-T)

4294967295 , i.e., 0xFFFFFFFF is an awfully BIG unsigned integer value to represent **-1,048,575 **? when 1048575 requires only 20 bits?

billy0305 · March 7, 2023, 11:08pm

Thank you for the response again.

I was not able to setup DW on RPi since the current DW only supports x86. Is there a workaround to make this work on RPi?
For some reason, reading and writing works now on RPi after I haven’t touched the robot in a while (I hate when it fixes itself…) I’ll continue to debug if the issue arises again.