RPi driving dynamixel from UART at 1Mbps

[Out_of_the_BOTS]

I have tested a proof of concept of driving a XL430 from the UART port of a RPi at 1Mbps.

The RPi has 2 UARTs: UART1 and mini UART. The mini UART isn’t stable at 1Mbps but the hardware of the UART1 is capable of much faster speeds than 1Mbps, the main limitation is the operating systems usage of the UART.

To get a stable 1Mbps from RPi UART I had to enable UART1 and increase the UART clock speed as the default clock speed is too low to generate UART at 1Mbps. I added the following 2 lines to the config.txt on RPi

init_uart_clock=16000000
enable_uart=1

Wiring:
I connected the RX pin of the RPi directly to the data line. The TX pin of the RPi will idle high so I connected the TX pin through a 4.7k resistor so that it will act as a pull up on the data line so that it can drive the data line but when the dynamixel transmits the dynamixel can sink to low against the pull up of the TX pin of the RPi. . This seemed to work really nicely as a converter from UART full duplex to half duplex. I connected the positive and negative of my Lipo 3S battery and also connected a common ground from the Lipo negative to the GND pin of the RPi.

I downloaded and installed the DynamixelSDK from Robotis github. I changed the baud rate to 1mbps and the port to the UART in read_write.py and ran the test script to test that the RPi could both transmit and receive to the dynamixel.

see https://www.youtube.com/watch?v=7tzznz7f3sU

[roboteer]

@Out_of_the_BOTS
Nicely done!

[Out_of_the_BOTS]

@roboteer
I have made up a prototype board on some perf board. It has the same circuits fro the dynamixel but I have added a fan for the RPi zero2’s CPU and a voltage regulator to step down the battery voltage to 5v to supply the 5v rail of the RPi so it can be powered of the same battery as the Dynamixels as well as stackable header so other hats can be added on top.

[Out_of_the_BOTS]

Here it is in action Standalone - YouTube

[roboteer]

@Out_of_the_BOTS
Super Cool!
Essentially, you created your own custom Dynamixel HAT for the RPi system. Thanks for sharing the detailed pictures showing how to put this HAT together. When you get the chance, can you share your BOM for this project?
Also, can you try to run the example “sync_read_write.py” with two XL-430s? This example has lots of DXL packets going back and forth in the DXL network. I am interested to see if your system can maintain no loss of DXL packets at run time. Previously, I was getting random packet losses at baud rates more than 115.2 Kbps in Python (but not in compiled C++) on the RPi4B.

[Out_of_the_BOTS]

@roboteer
re lost packets on RPi. With lots of googling and reading what other have done I have some understanding to the limitations of RPi UARTs. The RPi has 2 UARTs, usually the Bluetooth is attached to UART1 so make sure u have either moved the Bluetooth to mini UART or disabled the Bluetooth (I disabled the Bluetooth myself in config.txt).

The RPi UART hardware is capable of speeds up to 45Mbps but the operating system is the limitation. The OS standard setup runs the UART clock source to slow for reliable communications above speeds of 115200 but in the config.txt you add the line init_uart_clock=16000000 to increase the UART clock so it will be stable at 1Mbps.

The current HAT that I made is a bit of a prototype and I already have some ideas to improve it like using sideways mount JST EH so that the cables come out the side rather than up so that you can stack more HATs on top easy, I think that I will also add a 1000uf cap to the battery input because if you add lots of dynamixels moving all at once then you can get drops in voltage.

I think that I am going to draw up a PCB design and get if made up as this HAT and a RPi zero 2 could be a great combo for my robotic projects. The RPi zero 2 has the same processor as the RPi3 and RPi3 b+ but with the RAM mounted on top. Thermal dissipation governs how fast you can run the processor at, RPi3 ran at 1.2GHz but with RPi3 b+ they had a better packing of the CPU that got better heat dissipation so they ran it at 1.4GHz. The RPi zero 2 has the worst heat dissipation because the RAM is on top on the CPU and the zero form factor means less PCB to pull heat away. Lots of people have done a lot of testing with increasing RPi zero 2 speed and with a heat sink and fan everyone got very stable operation without over heating at 1.3GHz, this would put the processing performance of a RPi zero2 with fan and heat sink between a stock standard RPi3 and RPi3b+

[roboteer]

@Out_of_the_BOTS
Thanks for the details regarding RPi UART config settings, but I am still puzzled why using “compiled C++” worked OK for me though, while using Python3 failed for me, as I kept the UART configuration settings at their default values for both situations. And the Python code reported that it managed to change the baud rate OK to 1 Mbps, and the “sync_read_write.py” program worked most of the time, but it just had random packet losses, while the compiled C++ version never did. I’ll need to try that setting init_uart_clock=16000000 next to see if I get better performance out my Python programs.

[Out_of_the_BOTS]

@roboteer
OK that is strange.

Python is an interrupter that calls the under lying compiled C object.

The C library that you used to operate the UART would have to be telling the OS to change the UART clock source to be able to send/recive stable UART packets at higher speeds.

Either way it is the operating system that actually does the sending and receiving from the UART peripheral. The code python or C when sending just says to the OS here’s buffer of bytes can you sent it for me and when receiving from the UART the OS is constantly receiving and placing anything it receives in to a buffer and when you code want to receive it just asks the OS do you have anything already in your receive buffer for me.