POST No. 2408036
RPi Dynamixel SDK Python Code Works on Mac, Fails on RPi
2021-04-04 12:02:30 achudi

Hi guys,

This is my first post on the Robotis forum. 

My Raspberry Pi 3 communicates to two chained XL430-250-T Dynamixels using a U2D2. 

I ran "dynamixel_interface.py" on my Mac and it works completely fine (enables torque). This is the output: 

Succeeded to open the port 

Succeeded to change the baudrate 

Torque set to 0 for DXL_1 

Torque set to 0 for DXL_2 

When I run the same code on the Pi, I get this output: 

Succeeded to open the port 

Succeeded to change the baudrate 

[TxRxResult] Incorrect status packet! 

[TxRxResult] Incorrect status packet! 

I tried changing the clock in "/boot/config.txt" to 16000000, but it did not help. 

Does anybody have clues for why it works on my Mac, but flounders on the Pi?

2021-04-04 12:02:30
2021-04-05 11:00:55 Will Son


Have you watched the DYNAMIXEL quick start video for Raspberry Pi?

You may want to start running a single DYNAMIXEL first, then try the multiple DYNAMIXEL.

Also note that when running the example on Raspberry Pi, use linux_sbc folder.


2021-04-05 11:00:55
2021-04-07 11:45:20 Susan Mackay

I have an RPi that talks to 2 servos happily. 

However I had to modify the Python code in the 'port_handler.py' module.

The problem I had was that the RPi buffers the UART characters on transmit and exits the library code before the last character has been sent. Therefore the code that follows sending the command bytes changes the 'direction' GPIO setting too soon which messes up the reception of the status packet. (I was using an OpenCM 485 EXP between the RPi and the servos.)

I had to put in a small delay (calculated on the baud rate and the length of the command) before changing the 'direction' GPIO setting and that got it working nicely.

You have to be careful that the delay is not too long because the servos will start sending very soon after the last command byte is received. I have this delay set to the longest value but that is still quite a small window to get the timing right.

Of course this might not be your problem...


2021-04-07 11:45:20
2021-04-07 18:10:49 Will Son

Hi Susan,

Thanks for the thorough feedback on connecting DYNAMIXEL to RPi.

As you experienced, without using a communication converter like U2D2, it is quite annoying and troublesome to control the TX/RX pin direction as Linux OS is not good at keeping a decent timing.

According to our test with oscilloscope, the latency of controlling the GPIO pin was fluctuating and was difficult to fix a single delay value that works for all.

We might come up with an interesting idea that doesn't require this traffic control from SBC side.

2021-04-07 18:10:49
2021-04-08 12:03:55 Susan Mackay

My RPi was 'off air' whenI wrote my comment above. It's available again and I've captured the main change that I made:

   def writePort(self, packet):

        GPIO.output( self.directionPort, GPIO.HIGH)

        result = self.ser.write(packet);

#        time.sleep(self.tx_time_per_byte * (len(packet) - 2) / 1000)

#        time.sleep(self.tx_time_per_byte * (len(packet) - 1) / 1000)

        time.sleep(self.tx_time_per_byte * (len(packet) + 1) / 1000)

        GPIO.output( self.directionPort, GPIO.LOW)

        return result

I also changed the __init__ function to specify the 'directionPort'.

You will see various attempts to get the timing write as this seems to change from one RPi model to another. The earlier versions were on a RPi Zero W while the latest one is for a RPi 3A+.


2021-04-08 12:03:55
웹에디터 시작 웹 에디터 끝