USB2AX, a small powerful USB to Dynamixel controller
USB2AX, a small powerful USB to Dynamixel controller
by xevel
Mon Sep 05, 2011 12:15 am
While working on the Xachikoma, I felt the need for a very small USB adapter to talk to AX-series Dynamixels from my Beagleboard.
From there I got to work with a friend of mine to make one: the USB2AX, a small programmable USB to AX/MX series Dynamixel.
Open source firmware, open source hardware, powered byLUFA and based on parts of Arduino UNO and Adafruit's Atmega32u4 Breakout Board+ designs.
And since people asked me about it, I am working on a new version (understand: designed for manufacture) that might turn into a real product soon, if anyone is interested.
The most critical point about the USB2AX is its very small size. Here is a comparison of the first prototype with the original Robotis USB2Dynamixel.
This version was 28mm long, the next design will probably be a few millimeters longer due to the use of a real Type-A USB plug (for better reliability and durability).
The core of the system is an ATMega32u2, an USB-enabled microcontroller with 32KB of Flash, 1KB of SRAM and 1KB of eeprom running at 16MHz. You can find its little brother the ATMega8u2 as the USB chip of the Arduino UNO.
Possible firmwares:
- virtual COM port, much like the USB2Dynamixel [that's the one I used in my Xachikoma] (*)
- simple controller, possibly automating simple tasks, providing a queuing mechanism,... [this is what I really want to use in my robot, seethis post of the conversation linked below]
- custom user firmware. Ever wanted to build a Dynamixel-based joystick with force-feedback that appears as a plug&play joystick? now you can.
- maybe even a controller taking care of gait generation... but the computing power and available Flash memory might be a little scarce for that :/
(*) except if an application relies on FTDI-only APIs, but I don't know many which do that.
Flashing a new firmware can be done from the USB, no need for an external programmer.
Price: below the price of a USB2Dynamixel, somewhere in the 20-35€ area I think.
The obvious use is to save space, but I'm sure being able to reprogram it to fit your specific needs may be of interest to some.
Any thoughts?
A conversation about the how and why is already underway here, and while having a unique thread would be easier to manage, you can obviously use this thread too - I don't want to annoy anybody
.
Thanks!
From there I got to work with a friend of mine to make one: the USB2AX, a small programmable USB to AX/MX series Dynamixel.
Open source firmware, open source hardware, powered byLUFA and based on parts of Arduino UNO and Adafruit's Atmega32u4 Breakout Board+ designs.
And since people asked me about it, I am working on a new version (understand: designed for manufacture) that might turn into a real product soon, if anyone is interested.
The most critical point about the USB2AX is its very small size. Here is a comparison of the first prototype with the original Robotis USB2Dynamixel.
This version was 28mm long, the next design will probably be a few millimeters longer due to the use of a real Type-A USB plug (for better reliability and durability).
The core of the system is an ATMega32u2, an USB-enabled microcontroller with 32KB of Flash, 1KB of SRAM and 1KB of eeprom running at 16MHz. You can find its little brother the ATMega8u2 as the USB chip of the Arduino UNO.
Possible firmwares:
- virtual COM port, much like the USB2Dynamixel [that's the one I used in my Xachikoma] (*)
- simple controller, possibly automating simple tasks, providing a queuing mechanism,... [this is what I really want to use in my robot, seethis post of the conversation linked below]
- custom user firmware. Ever wanted to build a Dynamixel-based joystick with force-feedback that appears as a plug&play joystick? now you can.
- maybe even a controller taking care of gait generation... but the computing power and available Flash memory might be a little scarce for that :/
(*) except if an application relies on FTDI-only APIs, but I don't know many which do that.
Flashing a new firmware can be done from the USB, no need for an external programmer.
Price: below the price of a USB2Dynamixel, somewhere in the 20-35€ area I think.
The obvious use is to save space, but I'm sure being able to reprogram it to fit your specific needs may be of interest to some.
Any thoughts?
A conversation about the how and why is already underway here, and while having a unique thread would be easier to manage, you can obviously use this thread too - I don't want to annoy anybody
.
Thanks!
by PedroR
Mon Sep 05, 2011 9:48 am
Hi xevel
Your project looks excellent and is an ideal step forward in using AX/MX servos with more powerful MCUs (such as eBox or a full PC).
I have two points that I'd like to add to the discussion:
1) Will the firmware to emulate USB2Dynamixel support 3Mbps? This seems like the way Robotis is going, with the new MX-28 (and likely future servos)
2) With regards to emulating the FTDI protocol, there is one Robotis product that apparently relies on it: Roboplus.
This is not official information but there seems to be a "recommendation" to use FTDI based USB to Serial adapters when using Roboplus.
Considering the kind of project you're doing this doesn't seem to be a problem (most of Roboplus is written to program and interact CM-XXX controllers and not talk directly to the Dynamixel bus)
Finally, and as Limor mentioned, this is a very interesting product to stock here at RoboSavvy.
I'd like to add to Limor's post by saying that if you need help in mass producing the product we work with a couple of manufacturers who may be able to do that and hance we may be able to help you with that if you need.
Just let us know.
We look forward to seeing further developments of the board.
Regards
Pedro
Your project looks excellent and is an ideal step forward in using AX/MX servos with more powerful MCUs (such as eBox or a full PC).
I have two points that I'd like to add to the discussion:
1) Will the firmware to emulate USB2Dynamixel support 3Mbps? This seems like the way Robotis is going, with the new MX-28 (and likely future servos)
2) With regards to emulating the FTDI protocol, there is one Robotis product that apparently relies on it: Roboplus.
This is not official information but there seems to be a "recommendation" to use FTDI based USB to Serial adapters when using Roboplus.
Considering the kind of project you're doing this doesn't seem to be a problem (most of Roboplus is written to program and interact CM-XXX controllers and not talk directly to the Dynamixel bus)
Finally, and as Limor mentioned, this is a very interesting product to stock here at RoboSavvy.
I'd like to add to Limor's post by saying that if you need help in mass producing the product we work with a couple of manufacturers who may be able to do that and hance we may be able to help you with that if you need.
Just let us know.
We look forward to seeing further developments of the board.
Regards
Pedro
Last edited by PedroR on Mon Sep 05, 2011 12:10 pm, edited 1 time in total.
by i-Bot
Mon Sep 05, 2011 11:36 am
I can give some input on the second point.
I have tested the USB2AX code and found it to work well with Dynamixel Manager in Roboplus 1.0.23.0. Tested at different speeds and Firmware Recovery.
Some older Robotis and 3rd party software and libraries use the FTDI specific FT2XX.dll (windows) or ftdi_sio(linux), but there are plenty of alternatives which work fine with USB2AX. Maybe Robotis can comment on which of their software is/was FTDI specific ?
Not using FTDI means the performance of the USB2AX is better than USB2Dynamixel, due to lower latency.
I have tested the USB2AX code and found it to work well with Dynamixel Manager in Roboplus 1.0.23.0. Tested at different speeds and Firmware Recovery.
Some older Robotis and 3rd party software and libraries use the FTDI specific FT2XX.dll (windows) or ftdi_sio(linux), but there are plenty of alternatives which work fine with USB2AX. Maybe Robotis can comment on which of their software is/was FTDI specific ?
Not using FTDI means the performance of the USB2AX is better than USB2Dynamixel, due to lower latency.
by xevel
Mon Sep 05, 2011 11:53 am
Thanks for your replies!
@PedroR
Unfortunately, the ATMega32u2 with a 16MHz crystal is limited to 2Mbps. Using a faster clock while still being able to speak at 1Mbps is not an option.
To have better communication speed, I would have to upgrade to a 32-bit chip running quite faster (that's the idea of the big brother of the USB2AX: the USB2MX, but it's still just an idea for now and would be prohibitively expensive to develop I fear...)
Until now, I have not used the USB2AX faster than 1Mbps so I have to test if it really handles 2Mbps before answering completely this question.
i-Bot answered to your second point better than I could have
I have read tons of material about going from the cute little prototype you make yourself in your basement to designed-for-manufacturability product, yet I have still a lot of unanswered questions, and would gladly accept help in this regard, thanks!
Should I contact you by mail or would it be possible to do this in this thread/another dedicated thread?
@PedroR
1) Will the firmware to emulate USB2Dynamixel support 3Mbps? This seems like the way Robotis is going with the new MX-28 (and likely future servos)
Unfortunately, the ATMega32u2 with a 16MHz crystal is limited to 2Mbps. Using a faster clock while still being able to speak at 1Mbps is not an option.
To have better communication speed, I would have to upgrade to a 32-bit chip running quite faster (that's the idea of the big brother of the USB2AX: the USB2MX, but it's still just an idea for now and would be prohibitively expensive to develop I fear...)
Until now, I have not used the USB2AX faster than 1Mbps so I have to test if it really handles 2Mbps before answering completely this question.
i-Bot answered to your second point better than I could have
I have read tons of material about going from the cute little prototype you make yourself in your basement to designed-for-manufacturability product, yet I have still a lot of unanswered questions, and would gladly accept help in this regard, thanks!
Should I contact you by mail or would it be possible to do this in this thread/another dedicated thread?
by PedroR
Wed Sep 14, 2011 10:05 am
Hi Nicolas
(I have replied via PM.)
With regards to your project I have one additional question: in Robotis designs they seem to use a buffer (Tristate buffer).
I believe the purpose of the buffer is to store any data coming out of the PC while the USB2Dyn is "receiving" from the Dynamixel bus. This way nothing gets lost.
In your USB2AX which was the approach you took?
Are you buffering in software or did you just short RX and TX?
I was curious to ask this as this is quite an original approach and would really like to know more about it.
Thanks
Pedro.
(I have replied via PM.)
With regards to your project I have one additional question: in Robotis designs they seem to use a buffer (Tristate buffer).
I believe the purpose of the buffer is to store any data coming out of the PC while the USB2Dyn is "receiving" from the Dynamixel bus. This way nothing gets lost.
In your USB2AX which was the approach you took?
Are you buffering in software or did you just short RX and TX?
I was curious to ask this as this is quite an original approach and would really like to know more about it.
Thanks
Pedro.
by i-Bot
Wed Sep 14, 2011 11:42 am
There are a number of reasons to add a tristate buffer to devices which interface to the AX or MX bus.
1) Since the AX and MX bus are tristate bidirectional, then if the device cannot tristate its own outputs, then a buffer must be used on the output to the bus. The FTDI chips do not tristate, so this is an example of this.
2) If you want to stop data sent out by the device to the bus from being received back by the device then the buffer can also used placed on the input (note: pullup required after buffer).
3) If the device does not have sufficient voltage or current drive for the bus then a bufer is required. Typically this is where a 3.3V device is required to drive/receive the 5V AX bus.
4) Some devices have an RS485 or RTS mode where a pin can be set to toggle when data is being output, without software intervention. This is very useful when using DMA for output. The pin requires an external buffer to make the function work on the tristate bus.
In the USB2AX the AtMega 32U2 has outputs which can be tristated and the receiver is disabled internally to prevent reception of the sent bus data. It is also a 5V device so a buffer is not required in this case. The same configuration is used on the David Hylands designs.
Some Robotis designs need the buffer, some don't. I guess they always use it so code and interface is common.
I did suggest to Nicolas to add series resistors and protection diodes between the ATmega32U2 and the bus, then it will be as good as a USB2Dynamixel.
1) Since the AX and MX bus are tristate bidirectional, then if the device cannot tristate its own outputs, then a buffer must be used on the output to the bus. The FTDI chips do not tristate, so this is an example of this.
2) If you want to stop data sent out by the device to the bus from being received back by the device then the buffer can also used placed on the input (note: pullup required after buffer).
3) If the device does not have sufficient voltage or current drive for the bus then a bufer is required. Typically this is where a 3.3V device is required to drive/receive the 5V AX bus.
4) Some devices have an RS485 or RTS mode where a pin can be set to toggle when data is being output, without software intervention. This is very useful when using DMA for output. The pin requires an external buffer to make the function work on the tristate bus.
In the USB2AX the AtMega 32U2 has outputs which can be tristated and the receiver is disabled internally to prevent reception of the sent bus data. It is also a 5V device so a buffer is not required in this case. The same configuration is used on the David Hylands designs.
Some Robotis designs need the buffer, some don't. I guess they always use it so code and interface is common.
I did suggest to Nicolas to add series resistors and protection diodes between the ATmega32U2 and the bus, then it will be as good as a USB2Dynamixel.
by xevel
Wed Sep 14, 2011 4:30 pm
Indeed, like iBot said, tying RX and TX together and managing high-Z state programmatically is not a new trick.
David Hylands does it, the Arbotix controller uses it, and I've seen it used by other regular members of this forums too, to interface an arduino with the Bioloid bus
Thanks to iBot, the next version of the USB2AX will have a much more secure, and cleaner design. The counterpart is that it will be a little bigger (aiming at a size of 16x33m for the board including the USB plug, where the original was 12x28mm...).
(and for the record, Nicolas referred to in Pedro's and Ibot's posts = me)
David Hylands does it, the Arbotix controller uses it, and I've seen it used by other regular members of this forums too, to interface an arduino with the Bioloid bus
Thanks to iBot, the next version of the USB2AX will have a much more secure, and cleaner design. The counterpart is that it will be a little bigger (aiming at a size of 16x33m for the board including the USB plug, where the original was 12x28mm...).
(and for the record, Nicolas referred to in Pedro's and Ibot's posts = me)
by xevel
Sat Sep 17, 2011 8:01 pm
Here is some progress on the hardware.
Thanks to help from iBot, we finally added protection devices: ESD protection on the USB lines and TX/RX lines plus 47ohm resistors on the TX/RX lines, just like in the original USB2Dynamixel.
The Hardware Boot and Reset pins are now broke out on the side of the board, through a standard 0.1" header.
Decoupling capacitors are applied according to the recommendations of AVR042 and the ATmega32u2 datasheet.
The current size of the USB2AX is 14x33.1 mm (including the giganormous USB Type-A male plug), for a board where all the SMD components are soldered on the top side. Depending on the cost of manufacturing, we may change to put SMD components on both sides, and shorten the board a little more.
Eagle files are available in the Git repository : http://www.assembla.com/code/paranoidstudio/git/nodes/usb2ax/elec
This is the version (EDIT: except for the USB footprint that needs some fixing ) I intend to have a few prototypes made, if no critical flaw is found.
Feedback very welcome! Thanks!
Thanks to help from iBot, we finally added protection devices: ESD protection on the USB lines and TX/RX lines plus 47ohm resistors on the TX/RX lines, just like in the original USB2Dynamixel.
The Hardware Boot and Reset pins are now broke out on the side of the board, through a standard 0.1" header.
Decoupling capacitors are applied according to the recommendations of AVR042 and the ATmega32u2 datasheet.
The current size of the USB2AX is 14x33.1 mm (including the giganormous USB Type-A male plug), for a board where all the SMD components are soldered on the top side. Depending on the cost of manufacturing, we may change to put SMD components on both sides, and shorten the board a little more.
Eagle files are available in the Git repository : http://www.assembla.com/code/paranoidstudio/git/nodes/usb2ax/elec
This is the version (EDIT: except for the USB footprint that needs some fixing ) I intend to have a few prototypes made, if no critical flaw is found.
Feedback very welcome! Thanks!
by i-Bot
Mon Sep 19, 2011 1:56 pm
BRD looks good.
I like the move to through holes on the USB connector, so it could be wired direct to hub and avoid bulky cables/connectors.
Took a further look at alternative firmware. Added the SYNC READ function. Also removed one of the ring buffers which was not used, so now about 25% RAM and 16% Flash used.
I like the move to through holes on the USB connector, so it could be wired direct to hub and avoid bulky cables/connectors.
Took a further look at alternative firmware. Added the SYNC READ function. Also removed one of the ring buffers which was not used, so now about 25% RAM and 16% Flash used.
by xevel
Mon Sep 19, 2011 2:10 pm
Thanks i-Bot
The through-hole USB connector has also two other advantages compared to the SMD one : it's shorter (the whole USB2AX is now 32mm long with the plug), and I don't have to worry about it when it comes to soldering.
Its footprint has been fixed since the previous message, btw.
Do you have a repository of your own for the alternative firmware? Or do you want a writing access to mine? Anyway, I would really appreciate to be able to link to your work from the product page.
The through-hole USB connector has also two other advantages compared to the SMD one : it's shorter (the whole USB2AX is now 32mm long with the plug), and I don't have to worry about it when it comes to soldering.
Its footprint has been fixed since the previous message, btw.
Do you have a repository of your own for the alternative firmware? Or do you want a writing access to mine? Anyway, I would really appreciate to be able to link to your work from the product page.
by xevel
Tue Sep 20, 2011 4:49 pm
Board design for version 3.0a will be finished this week(it's mostly silkscreen layers that still needs work), and I will order prototype PCBs (8 days turnaround).
Since I'm lucky enought to be granted acces to a manual pick&place and a reflow oven, I should be able to assemble a few of them (6-12) for beta testers, and will dispatch them immediatly.
More to see soon, I hope
Since I'm lucky enought to be granted acces to a manual pick&place and a reflow oven, I should be able to assemble a few of them (6-12) for beta testers, and will dispatch them immediatly.
More to see soon, I hope
by xevel
Fri Sep 23, 2011 3:57 pm
Proto PCB ordered. I should get them at the end of the month, or around the 10th, due to holidays in China, from October 1st to 7th.
I will assemble maybe 10 boards, but I ordered some more PCB, since thay are so small and the damage (tooling cost) is already done. Worse case scenario, I will have lots of tiles to make a geeky mosaic
This final product might differ from the proto, depending on the answers the manufacturer will give to the questions I asked some times ago... still waiting...
I will assemble maybe 10 boards, but I ordered some more PCB, since thay are so small and the damage (tooling cost) is already done. Worse case scenario, I will have lots of tiles to make a geeky mosaic
This final product might differ from the proto, depending on the answers the manufacturer will give to the questions I asked some times ago... still waiting...
by xevel
Fri Oct 07, 2011 4:09 am
I received the PCBs on Monday as planed, yet could not assemble them until yesterday since I caught a bad cough.
Assembling 0402 and fine pitch QFNs (especially the ESD protection chips, these beast have 6 legs under a 1x1.45 mm body...) with a manual pick and place is both fun and a pain. It's like playing a game in hard mode: not impossible, but you have to really bust your ass off to succeed, and it gives a real sense of accomplishment :p
Fixing stuff (like a slightly out of place 0402 resistor) with a good ol' iron is even more fun, especially while coughing from time to time, with the risk of making small parts fly
I have a dozen functional (and disinfected xD) boards, ready to be sent to beta-testers. I have enough parts to make up to 25 of these, so if anybody wants one before the release of the professionally assembled one, just send me a PM.
The code in the git repository has been updated to encompass the slight differences between the first prototypes and this one, named v3.0a.
@ibot: I would love to see the code you hinted at previously, with the SYNC_READ command and the other improvements