Servo - January 2012

FIGURE 1. MX- 28 out of the box, with horn, thrust washer, hardware, and cable.

main body of the servo is identical except for the electrical connector is three-pin instead of four-pin. The version of the RX- 28 that I used in the hexapod was purchased a few years ago, so the servo horn was a bit different style. The threaded servo horn holes have actually been drilled on a slightly different radius. The newer horn style has threaded holes on a 16 mm diameter, whereas the older horn style has holes on a 17 mm diameter. When upgrading, it is important to make note of this as any brackets will need to be redesigned or drilled out.

Fortunately, this issue is fairly minor compared to the different communication bus. The serial control protocol is still identical, however, Robotis switched the protocol from the RS-485 bus to bidirectional half-duplex TTL communication. This transition is nice in that it reduces the overall wiring which will definitely be helpful when trying to cram all the excess wire inside the hexapod body. I believe the TTL bus also consumes a bit less power than the RS-485 bus. The USB2Dynamixel supports the TTL bus as well, and now the MX- 28 can be daisy-chained directly to the AX- 12 or AX- 18 actuators.

Unfortunately, the half-duplex TTL bus is not as well supported outside of Robotis. Before, it was possible to get any FTDI based USB to RS-485 adapter and very quickly run some Linux code and begin communicating. Without the USB2Dynamixel, a method of tristate buffers (like chips

74HC125 or 74HC126) must be implemented to communicate through a standard UART or FTDI chip. It is by no means a difficult circuit to build; it is just not quite as plug and play as before. It’s nice to see that Robotis appears to be making a move to have all their motors use the same protocol. Anyone already set up with the AX-series will definitely be happy with the new transition. I would think that when the MX- 64 and MX-106 come out they may also have the TTL bus.

Inside the MX- 28

Opening up both the MX- 28 and RX- 28, we can see a bit of what is going on internally. In Figure 3, the RX- 28 is on the left, showing the L6201 H-bridge. On the right is the MX- 28, showing the 72 MHz STM32F103C8T6 ARM Cortex M3 processor — which is quite a step up from the ATMega8 in the RX- 28. Both motors include a spot for a programming header, enabling any hacker to quickly load up their own code. Figure 4 shows the opposite side of the MX- 28 board. Here, the 74HC126 tristate buffer is visible, as well as the AS5045 magnetic potentiometer. Still in the body of the servo is the magnet attached to the output shaft. Clearly, the old slot for the potentiometer used in the RX- 28 still exists, meaning that the body is most likely interchangeable with the RX- 28. Figure 5 shows the gearbox of the MX- 28.

The magnetic sensing is what puts the M in MX- 28. This is the most exciting part for implementing the motor in the hexapod as it will never wear out since there is no mechanical contact. The AS5045 uses a set of Hall-effect sensors to determine the orientation of the magnet. The previous continuous turn potentiometers eventually became worn after running the hexapod for an inordinate amount of time. The magnetic sensing also extends the angle control range to a full 360 degrees (from 300) at a 12-bit resolution (from 10-bit). This increases the precision from .293 degrees to .0879 degrees. That is a total factor of 3. 33 times better.

The new ARM processor is able to bump up the communication bus to include three newer baud rates at 2250000, 2500000, and 3000000. I will definitely be implementing the newer baud rates which will make the hexapod operate as a much smoother machine.