Use the following template to help create your post:
What model of servo are you using?
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
Daisy chained motor connection
Single motor connection
Inconsistent motor detection on Raspberry Pi
- Include pictures if possible.
U2D2 overall connection
- 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
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?
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.
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.
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?
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.