View Full Version : Dynamixel MX28

08-18-2011, 12:53 AM
Just noticed the new mx servo from robotis with 360 capability. I'm working on a turret project and am wondering if this servo could be used instead of a stepper motor. The question is: what happens when horn is at position +179 and it is told to move to -179 degree position? Will it move 2 degrees or go around the whole 358? It was not clear from the commands in specs how can I control this behavior.

08-18-2011, 01:12 AM
It will move 358 degrees.


08-18-2011, 07:37 AM
Of course, since it has 360 degree (12-bit) magnetic position sensing even in wheel mode, you could add code to your controller to: 1) change it to wheel mode, 2) move it the two degrees past the range limit/barrier, 3) return it to servo mode, and 4) give it the new goal position which it will then hold.

If you were feeling really adventurous and have a decent understanding of the ARM Cortex-M3 (specifically an ST32F103C8), then you could potentially replace the Robotis firmware on board the MX-28 with your own that will behave exactly as you want it. I do not recommend it unless you are very sure you want to have a $220 brick on you hands. Robotis does not release much about the internals of their products, and figuring out how everything is connected (and how the bootloader works) to successfully reprogram it makes this a great deal more complicated then just using a stepper motor or some extra code to control a stock MX-28.

You could always just add a similar magnetic encoder and a small magnet to the back of the stepper motor's shaft to get accurate position sensing in case the motor ever slips during a step or if you are using micro-stepping. With that sensor feedback, you could build your own closed loop controller to control the stepper motor similar to a servo. The only problem is that stepper motors do not usually scale very well (higher torque without a gearing system means rather large/expensive motor), hence the common usage of relatively small and inexpensive high speed motors with speed reducing gearing systems and position sensing on the output shaft (a servo).

08-18-2011, 07:45 PM
Thanks for the input!
There are few reasons why I thought servo is better than stepper:
1) smaller + lighter
2) does not consume power if there is no load
3) position feedback
4) comes with gearbox
I was thinking about switching to wheel mode and back but was not sure how it would perform if turret will need to follow a randomly moving object just around the "dead point". For example, will it hold the load while I reprogram it to wheel mode? Probably, only real world test can answer that...
Is it possible to read position while in wheel mode?
BTW, I'm going to use roboard 110 for controlling it. It has native support for RS485 up to 500Kbit to connect RX series dynamixels. What would it take to connect MX28 to roboard say @1Mbit?

It would be a nice feature for 360 deg servo to have a command for relative move: say, turn "10 degrees clockwise from current position". Or specify the direction for each absolute position.
Currently the target position implies direction which is sort of an artificial limitation for a servo which is capable of full turn.

08-18-2011, 10:07 PM
The "MX-28" uses the same three pin TTL-level half-duplex UART as the AX-12/18 (NOT RS-485 or RS-232), with the only difference being that the "MX-28" can achieve 3Mbps (newer ARM Cortex-M3 processor at 72MHz in the new servo(s) [MX] versus an ATmega8 at 16MHz in all of the older servos [AX, DX, RX, EX]).

Position sensing should be available in both Servo and Wheel modes. For the transition around the barrier in wheel mode: if the servo is moving, you could get the current speed in servo mode and use that as the target speed in wheel mode. You could then be constantly checking the current position of the horn while in wheel mode, and switching back to servo mode after moving 1~5 position counts past the servo mode rotation barrier. Immediately after getting past the barrier and back into servo mode, just give it the final goal position and reset the moving speed to whatever you normally used.

Although the MX-28 is a significant improvement over most other hobby-like servos, it still is expected to behave like one as most joints where such servos are used cannot rotate more than 360 degrees (not intended for continuous rotation like a stepper motor). If you want to use it in a relative mode, you will need to create a function to keep track of its current position and just process the relative inputs to work around the barrier. You could also try using only the position sensing and wheel mode to try to implement your own position controller (as the firmware of the MX-28 does with its on board processor). Or you could try making a feature request for a relative mode on the Robotis QnA or maybe even send them an email asking if it would ever be a possible feature in a future firmware release. Or you could give it a try writing your own firmware (not recommended unless you have experience with programming for ARM microprocessors and somehow acquired the full schematics for the MX-28 from Robotis [snrk...SNRK...bwahahahahaaaa (http://www.robotis.com/xe/qna_en/69858). I couldn't even get a simple replacement part number (http://www.robotis.com/xe/45527)]).

08-19-2011, 08:40 AM
It would be a nice feature for 360 deg servo to have a command for relative move: say, turn "10 degrees clockwise from current position". Or specify the direction for each absolute position.
Currently the target position implies direction which is sort of an artificial limitation for a servo which is capable of full turn.

In the MX-28 beta survey, I asked for this relative mode and a multi-turn absolute mode as well... and here (http://www.robotis.com/xe/PowerUsers_en/74479) too I gave a word in favor of such features.
Maybe if enough people ask for it our prayer could be answered *crosses fingers*.

08-19-2011, 02:10 PM
Thank you for the answers. Nice to see I'm not alone.
BTW, does anybody know is there a 360deg servo around which has this "relative move" feature?

08-19-2011, 02:54 PM
The Supermodified (http://www.01mech.com/supermodified) might be of interest to you.
Basically, you gut a standard hobby servo and replace the electronics (control board and potentiometer) by the Supermodified board sandwich, composed of an Atmega328 (same as in the arduino Uno/Duemilanove, and flashed with the old arduino bootloader), a beefy motor driver and nearly the same magnetic encoder used in the MX-28.
It's open source and well documented. Main downside: you have to mount it yourself into the servo (or send them your servos to have it installed in it... I don't know if they charge for this service, but it's in Greece so the shipping would already cost you some money.)

I have a few of these and as long as you mount them properly, they work as advertised: relative mode, multi-turn absolute mode, hi-resolution (same as the MX-28), good PID controller, ...
It's fairly simple to mount it in Hitec servos, but if you like other brands be aware that you might have to work a little bit more to have everything in place.
I mounted one in a MG955 with relative ease (but I don't recommend it, MG995 are complete crap), and one in a more exotic Bluebird hi-speed servo (which involved heavy modifications to make the Supermodified fit).
Here is an example where I told the servo to do +360° every few second:


The standard interface is I2C, but all the code is available if you want to use a different way to communicate with it. It would even be possible to make it talk like a Dynamixel, but this would require some modification of the board, like changing the crystal to a 16MHz one, and writing some code...
The website hasn't been updated since 2010 however, I hope they are still in business :/ (if not, I might have a few spare Supermodified I don't use if you're interested).

12-01-2012, 05:09 AM
Some time ago we actually tried out the relative move approach of switching the MX28 to wheel mode to get over the dead point and then polling the position, and then switching back to servo mode to hold it in place when it reaches the position. It kind of works, with the latency and overshooting that you would expect with all the communication involved. Though, the reason why I would not use this approach is that the wheel/servo setting is a persistent setting - changing it often enough will wear down the flash or eeprom that stores it. And also I think I got a feeling that it took time to actually change the setting, which adds even more latency.

The interesting part is that internally the servo is capable of doing that. If you position it right at the edge, say at position of 2 units (whatever they are), and then by hand force it over the edge to a position like 4094, it will of course return to the goal position by going back the 4 units, not the whole way around :) So, I imagine the only firmware hack that is required is when it determines the direction in which to go when it is given the goal. That feels like a very small change. I may even be tempted to try it. I have never tried the firmware update tool, but since it exists I guess it should be possible to acquire the firmware file and mess with it before actually upgrading. Or maybe someone has heard of a tried and true method to hack the dynamixel firmware?

Or maybe ROBOTIS have already implemented the relative move, need to go check their updates...

12-01-2012, 11:09 AM
They just added some torque control functionality, but no relative move yet. The DARwIn-OP framework has not been upgraded in a while, so it is still using servo firmware from several revisions ago. The servo firmware is only released as a pre-compiled binary file, so modifying it would be a bit difficult without a program to convert the binary to human readable op-codes and registers/addresses (even then you have to figure out what everything is doing because there would be no usable names included in the code). Creating your own firmware would require a full schematic of the MX-28 control board and more or less start from scratch (could use a bit of the CM-530 embedded-c code as a starting point).