After much deliberation, I ended up going with the Bioloid. It's one of the more well documented robots with a healthy developer community, and it's highly reconfigurable. It comes with an "errector set"-like kit which allows you to build a variety of robots, not just humanoids. However, this modularity comes at the cost of extra weight. So, while the power-to-weight ratio of the servo motors maybe comparable to the higher-end robots, the overall performance of the robot is noticeably slower and clunkier. It also happens to be one of the cheaper robots at$900. I really liked the re-configurability (for future robot projects), the number of degrees of freedom (particularly in the hip), and the size of the community support/English documentation.
When I first got it, I was a little intimidated by the number of pieces in the box. Being an educational robot, I was hoping it was going to be a quick and simple setup. While the instructions are fairly easy to follow, it did take me about 5 hours from opening the box to a completed robot. Assembly requires handing many similar looking parts and lots of tiny screws. However, it is very satisfying to see the robot slowly take form as you assemble the components.
Once it is done, you do get an urge to say out loud "IT'S ALIVE!" with a grin on your face.
The included CD does have software to program and contol the robot, but as I expected, it is somewhat limited to keyframe pose playback or simplfied visual programming. My original intent was to run the robot using my own C/C++ or C# program. So, I didn't spend much time with the included software other than to verify the robot worked and to get an understanding of the control flow. The C development tools described by the documentation are for writing programs that run on the Atmega128 chip inside the robot. What I wanted was to run the control logic on my PC. However, getting my own software to control the robot ended up being quite a bit more challenging than I had expected.
The first major hurdle I had was the physical connection. The kit comes with a serial cable for communication with the robot, but it uses a DB-9 connector that is only found on desktops these days and my main machine is a laptop. The Bioloid has an expansion slot on its control board, the CM-5, for a wireless Zigbee connection. There are a few resources online explaining how to use a Bluetooh Module instead of a Zigbee module. So, I had ordered a BlueSMIRF module (WRL-08332) from Sparkfun in anticipation of doing this.
The Bioloid controller requires 57600 baud serial communication, but the Bluetooth modules typically come set to 9600 baud. To my frustration, the information on Sparkfun's website on exactly how to re-configure the baud rate is a little obtuse. They have different chipset versions with different command sets. Something I burned about 2 hours learning was that newer modules, with the BGB203 chip, CANNOT be configured wirelessly over the Bluetooth connection. They have to be configured via the wired TTL TX/RX connections. Moreover, to change the baud rate and save it to memory requires a TTL connection that can dynamically change its baud rate to issue the "save to memory" command at the new baud rate. My short lived attempt at trying to using a second Bluetooth module was a failure because while it could issue the "change baud rate" command it could not issue the "save to memory" command. =oP Anyway, once I got my hands on a USB TTL-232 cable, things went smoothly. One other important thing to check is the Bluetooth passkey of the module (using the configuration commands). In Vista, to make the Bluetooth serial port binding behave nicely I had to configure the bluetooth connection to use the passkey. It happened to be set to "0000" on my module despite the documentation from Sparkfun indicating it would be "default".
The second problem I ran into was that once I connected the Bluetooth module to the Zigbee communication pins, I discovered that it is NOT A REPLACEMENT for to the PC LINK serial programming cable port at the top of the CM-5. The data from the Zigbee unit is only meant to provide command bytes triggering behaviors in a program running natively on the CM-5. What I wanted was raw access to the servos so I could run control logic on the PC. This can only done via the PC LINK. The data from the Zigbee module never makes it to the servo motor bus. So after some digging, I found a schematic for the CM-5 and found where to piggy back data onto the main PC link. The image below shows where I connected my wires. The TX from the Bluetooth module is attached to the logic level side of the RS232 level converter. The other wires are connected to the Zigbee pins as decribed by the reference above.
This defintiely at your own risk and may behave badly if you try to connect the wired PC link cable at the same time. But since I intend to only use the Bluetooth serial connection, this was not a concern for me.
Now, I can run the included software such as Motion Builder using the Bluetooth connection as if I had the wired PC Link cable attached. Great! The CM-5 provides some commands such that if you open up a ternimal window to the serial port, you can get/set the data for each servo manually. However, the human readable commands use A LOT of bandwidth overhead. Given that the 57600 baud connection is already runnning much slower than the 1000000 native baud rate of the Dynamixel AX-12 servo motors, trying to control the robot via these commands was unbearably slow even if executed programmatically and I kept running into buffer limits on more complex commands.
A not-very-well documented mode of the CM-5 is "Toss Mode" which appears to be a pass through mode to the servo motor bus. Put the CM-5 in Manage Mode, and hit the Start button. In your PC's terminal window, type "t" then hit enter. It should respond with "Toss Mode". At this point, any bytes sent via the serial connection is pushed directly onto the servo motor bus and vice versa. Finally! Exactly what I wanted. After slowly making my way through the Dynamixel AX-12 User's guide, I now have a small C# library that provides direct control/communication with the servos via the serial port. It's still pretty rough but once I clean it up a bit more, I'll probably make it available for download. But, it is a farily straight forward implementation of key commands from the Dynamixel users manual. The hard part was getting the hardware into the right configuration to allow direct communication.
The next step to do is write my own control and logic software to see if I can make it do more interesting things than simply recall preset poses. There's also a mild annoyance in that the 57600 baud serial link is about 17x slower than the 1000000 baud servo bus speed. If this becomes an issue, I might explore making an alternative controller board that would provide 1000000 baud pass through, or even put each limb on a separate bus to parallelize I/O making it even faster. This could result in a 70x speed bump in servo communication which would be helpful with real-time control logic.
(update 4-22-09) It looks like Scott Ferguson has C# libraries for controlling a dynamixel directly via a serial port. He was using a USB2Dynamixel adapter. The bad this is that it doesn't provide power to the servo, only control. So, using the CM-5 a wirelss control/power brick is still fairly attractive.
No comments:
Post a Comment