Articles & Tutorials

Dynamixel AX12A servos

These are very capable and handy devices for hobby robotics.  It has a pretty good manual, but here are some extra  notes and links that I’ve gathered.  This is a working document.

Hardware details

  • Circuit diagram (reverse engineered) for the motor and CPU.
  • The CPU is an Atmega128
  • Position is sensed with a Murata continuous turn potentiometer connected to an ADC pin.  It measures position of the output shaft.
  • The motor is PWM controlled by a FET h-bridge
  • There is no ability to sense motor current.
  • Communications is via a half-duplex TTL-level serial link at upto 1Mbps.  
    • Each byte is sent with one start bit, one stop bit and no parity bits, therefore 10 serial bits per byte transferred.  
    • At 1Mbps that’s 10μs per byte, or 80μs for a typical message.  The response will be another 80μs, for a total of 160μs to read/write a single servo parameter.
    • The AX12 has a control parameter to delays its response to allow the half-duplex channel to turnaround.  That defaults to 500μs.  It can be set to zero, but the minimum amount of processing in the CPU means the smallest value in practice is around 20μs.
    • The total time to read/write a single parameter therefore varies between 180-760μs.
    • The protocol is not very efficient when it comes to reading/writing multiple servos at each control cycle.
    • Analysis of latency (PDF) suggests that the servo takes over 17-50ms to begin moving after a command is received.
    • Details of communications protocol
  • In general you’ll need some kind of adaptor to connect it to a host computer
    • Arbotix-M board from Trossen Robotics which can pass through Dynamixel packets (with a latency of one packet) in each direction, or be programmed to implement some “macro” function in its own right.  It connects to a host using an FTDI (TTL-level serial) to USB cable such as this (not included)
    • U2D2 USB to TTL converter from Robotis

Software details

  • The AX12 runs the v1 protocol which allows the host to read/write bytes in a memory (EEPROM or RAM) table.
  • The “Reg write” instruction allows commands on multiple Dynamixels to be setup and then a single broadcast ACTION instructions makes it happen.  This is great for simultaneously setting position set points.  
  • Simultaneous read of position (or other motor parameters) cannot be achieved using the broadcast address. This is a capability of the v2 protocol for the MX-series Dynamixels.
  • The term “torque” is used a lot in the documentation but is really just the PWM command (effectively the motor voltage which is proportional to speed in steady-state motion).
  • Motion control is essentially a trapezoidal velocity profile.  

Timing via Arbotix board

This board from Trossen Robotics is now obsolete, replaced by the ArbotixM.  It receives Dynamixel packets over a serial port at 38400baud, then forwards them to the Dynamixel at 1Mbps, receives the response at 1Mbps then forwards it to the host at 38400 baud.  The latency is therefore quite high.  The expected value can be computed in MATLAB

function t = comms(down, up)
    bt1 = 10/38400; % serial port byte time
    bt2 = 10/1e6; % ttl port byte time
    rd = 250; % AX12 receive delay parameter
    t = (6+down)*(bt1+bt2) + rd*2e-6 + (6+up)*(bt1+bt2);

For a get position message (2 byte payload down and back) the total communications time would be

>> comms(2,2)
ans =

or just under 5ms.  A benchmark program, running in MATLAB (18b on a MBP running Mojave), shows a mean time of 29.1ms with a standard deviation of 6.9ms, median time of 29.5ms, and a maximum of 70.3ms.  Of this time, the profiler indicates that an average of 24.6ms spent in the fread() function and 21.8ms spent in the Java serial communications call.

This indicates that overhead on the host and/or the USB serial adaptor dominates.  To read 5 servos takes just over 100ms.  There would be advantage in implementing functionality in the ArbotiX that reads 5 servos and returns them in a single message.


  • The Arbotix is connected by a USB serial cable using an FDTI chip.  Performance depends critically on the USB chain connecting this chip to the CPU.  Via USBC-Thunderbolt2-USB2hub-FDTI timeouts and checksum errors were frequent.  Via USBC-USB3 adaptor performance is much better. 
  • The serial port, while open, seems unresponsive for some seconds after it is opened.  Packets are apparently written but reads timeout.  This has been observed on a Mac+MATLAB as well as RaspberryPi+Python+pyserial system, the common factor being the FDTI chip.  There are some online references to this chip requiring some time to process serial port configuration changes.
  • Latency in the FDTI chip, see this post.


Other resources

View all posts