View Full Version : [Question(s)] Dynamixel SDK (Robotis)

08-25-2011, 10:30 AM
I have a question... does anyone know if it is possible to control in parallel two Dynamixel motors, one connected via RS485 and one connected via TTL ?
I will make my question clearer... Let's immagine that Ihave two USBtoDynamixel keys connected to our PC, one is connected to a RX28 and one to a MX28, for example. I set two COMs differently, let's say COM5 and COM6.
Can I launch

dxl_initialize( PORTNUM, BAUDNUM);

twice but with different portnum? Let's say COM5 = 5 and COM6 = 6, can I do like this?

dxl_initialize( 5, DEFAULT_BAUDNUM);
dxl_initialize( 6, DEFAULT_BAUDNUM);

In case if possible, if I want to terminate the communication I have to use


but how can I choose which port? Will I terminate the communication for both
Last question... If I can launch the two dxl_initialize(), and then I launch an instruction, I will go to both servos?

08-25-2011, 01:41 PM
With the default Robotis provided PC-based Dynamixel and Zigbee SDks... No.
I created a modified version of the Win32 Zigbee SDK (here on the Robotis QnA (http://www.robotis.com/xe/52458)) and it will be simple enough for you to modify the Dynamixel SDK to match that functionality. I seem to remember posting about this in another thread somewhere on the trossen forum, but I cannot find it right off. I may just be imagining things.

03-02-2012, 12:39 AM
Hi Pocar19,

Yep it's definitely possible, basically u can modify the source of the dynamixel SDK so that instead of having a single handle to an FTDI chip, there is an array of handles to multiple FTDI's. You can then modify every function to pass in a index which specifies which handle to use.

I did this and it worked pretty well, but ultimately I got the shits with the dynamixel SDK because overall it's not exactly the best code out there. eg there was an annoying latency problem which was hard to track down, and it doesn't throw errors properly (it also uses "goto's"). And, the "sync write" is not implemented properly.

I ended up just forging packets using my own code and the FTDI API directly, this was actually pretty easy and works much more effectively. Here's a link to the programming guide:
www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf (http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf)

03-02-2012, 02:00 AM
The latency problem is due partly to the robotis code (not all flags are used/checked and does not delay between checks for a completed packet causing CPU load issues) and more because of the OS. Opening a basic serial port in windows with a latency of zero does not change the actual device driver's latency setting (must be changed in Device Manager). Not too sure about Linux or OSX, as I have not really used them with an FT232 in low latency scenarios.

I do not recall ever having problems with the sync_write command on the PC (no problems with the embedded versions). Using the sync_write function is not as simple as the read/write_byte/word function, requiring a bit of knowledge of the actual packet layout (must correctly place each byte manually).

As for the "goto" commands: they used "goto" commands in "dxl_hal.c" only for the single function to open a Windows COM port instead of deeply nested if statements to make the code more readable (i.e. not a factor during RX/TX).

03-02-2012, 02:30 AM
Hmm, you may be using a different version to me (I'm using 1.02). My main beef with sync write is that the example code has you creating the frame directly:

// Make syncwrite packet
// Method 1.
gbInstructionPacket[ID] = BROADCAST_ID;
gbInstructionPacket[PARAMETER] = P_GOAL_POSITION_L;
gbInstructionPacket[PARAMETER+1] = 2;
for( i=0; i<NUM_ACTUATOR; i++ )
gbInstructionPacket[PARAMETER+2+3*i] = id[i];
GoalPos = (int)((sin(theta+phase[i]) + 1.0) * 512.0);
printf( "[%d]:%d ", id[i], GoalPos );
gbInstructionPacket[PARAMETER+2+3*i+1] = dxl_get_lowbyte(GoalPos);
gbInstructionPacket[PARAMETER+2+3*i+2] = dxl_get_highbyte(GoalPos);
a = dxl_get_lowbyte(GoalPos);
a = dxl_get_highbyte(GoalPos);
printf( "\r" );
gbInstructionPacket[LENGTH] = (2+1)*NUM_ACTUATOR+4;

Whereas for the other calls, the frame creation is done within the dll. It's inconsistent. This was the point where I thought to myself, if I'm creating frames myself, why not just use the FTDI API directly - which did turn out to be a cleaner solution (imho).

Btw, the "latency" problem was more of a timing problem (I used the wrong word) where I was polling an address but the servo wasn't responding fast enough, causing the function call to time out too quickly. Not sure why I'm the only who experienced this one, oh well.

03-02-2012, 08:27 AM
I see your point about sync_write not being consistent in how the packet is built versus the other read/write functions, but then the other functions use fixed packet structures (sync_write is unique to each situation - how many servos, how many bytes, etc.). The best alternative I can think of is using one function to initialize a sync_write packet (clear internal buffer and servo data index), another function to build each servo's portion (and increment servo data index), and a third function to send the entire packet.

// format the sync_write buffer
sync_write_begin(int numServos, int numBytes, int address);
// {0xFF, 0xFF, BROADCAST_ID, (numServos*numBytes+3), INST_SYNC_WRITE, address, numBytes, ...}

// Copy each servo's id and write data to the next place in the buffer
sync_write_middle(int servo, char* data);
// Could add other functions to take common integer lengths (char, short, long) and build the array
// before calling this function to add it to the buffer.

// Compute Checksum and send packet

Not sure I have encountered the "timeout because of polling too quickly problem", but its existence would not be terribly surprising.

Rather off the original topic, but I had a problem getting a useful frame-rate from the HaViMo2 (with USB2Dynamixel on WinXP) because of the latency/delay between the FT232 receiving some data from the DXL bus and actually deciding to send a USB packet to the PC (as well as waiting too long for ping packets to timeout and/or not waiting the correct amount of time between attempts to ping it to confirm a new image has been processed). Abandoned the PC approach and finally got the HaViMo2 working rather well (http://www.robotis.com/xe/112764) with the CM-510/530. Now I need to make the bots do something useful like soccer instead of just overly simple pan-tilt blob tracking (hopefully add a bit of velocity/direction prediction so it doesn't lose track so quickly).