Dynamixel AX-12A won't actuate if the chain is longer than 6

[zhanginou]

Hi,

I am building a quadruped robot using 2 Dynamixel AX-12A per limb, so 8 in total, all daisy-chained on the same Serial line of my Teensy 3.6.

I am using the library developed of Savage Electronics (https://sourceforge.net/projects/dyn...?source=navbar) in which I added the function Sync Write in order to actuate multiple servos at the same time (and I don't need any Status Packets so it suits me more than to use the Reg Write and Action functions).

I am sending the instruction Sync Write every 10ms to 8 Dynamixel AX-12a.

Strange things start happening after I daisy chain more than 6 servos together:
- the servos stop altogether if I don't touch anything
- the servos move again but are very jittery at some times (not always) when I'm tweaking the wires
- after a while of tweaking and jittering, often one of the servos' ID is reset (in which case I have to set it again to the ID I want it to have)
- when I daisy chain 6 servos only (in which case it's supposed to work), but just for the sake of it decide to plug in an extra JST cable in one of these servos and let it hang (i.e. not connect it to another servo on the other end), the 6 servos just stop moving altogether

I suspected in the past this to be a wiring problem (because of the tweaking) so I ordered new, shorter, wires from Trossen Robotics, to no avail.

For some time I was using REG WRITE and ACTION to actuate multiple servos and I suspected the problem to come from that, so I added the new function Sync Write into Savage Electronics' Dynamixel Library, to no avail.

One last thing: when I daisy chain the servos directly by using the pins on the servos, the movements are jittery even with just 4 servos. However when I daisy chain them externally using a breadboard the movements are smooth. Do I need to change servos? Is this a servo issue? They are around 2 years old and have been used quite a lot. I don't have reason to suspect this is the real issue though.

Details on the power I'm using:
- 11.1V 3S 1100mAh 25C LiPo Battery -> goes in the 8 Dynamixel AX-12A
- 11.1V from the battery goes through a 5V Voltage regulator which goes in the 5V pin in the Teensy 3.6 (which has an internal 3.3V voltage regulator)

If anyone has had a similar issue, or might know what the cause of my problem could be, please post a comment!

Victor

For info, here is the Sync Write function I added:

void DynamixelClass2::syncWrite(unsigned char ID[8], int Position[8], int Speed[8])
{
    int SYNC_WRITE_LENGTH = 44; //(4+1)*8 + 4 = 44
    char Position_H[8], Position_L[8], Speed_H[8], Speed_L[8], Sum_Position, Sum_Speed;
    Sum_Position = 0;
    Sum_Speed = 0;
    unsigned char Sum_ID = 0;
    for(int i = 0; i<=7; i++){
      Position_H[i] = Position[i] >> 8;    
      Position_L[i] = Position[i];                // 16 bits - 2 x 8 bits variables
      Speed_H[i] = Speed[i] >> 8;
      Speed_L[i] = Speed[i];                      // 16 bits - 2 x 8 bits variables
      Sum_Position += Position_H[i] + Position_L[i];
      Sum_Speed += Speed_H[i] + Speed_L[i];
      Sum_ID += ID[i];
    }
    
  Checksum = (~(BROADCAST_ID + SYNC_WRITE_LENGTH + AX_SYNC_WRITE + AX_GOAL_POSITION_L + AX_MOVING_LENGTH + Sum_Position + Sum_Speed + Sum_ID))&0xFF;


    sendData(AX_START);                // Send Instructions over Serial
    sendData(AX_START);
    sendData(BROADCAST_ID);
    sendData(SYNC_WRITE_LENGTH);
    sendData(AX_SYNC_WRITE);
    sendData(AX_GOAL_POSITION_L);
    sendData(AX_MOVING_LENGTH);
    
    sendData(ID[0]);
    sendData(Position_L[0]);
    sendData(Position_H[0]);
    sendData(Speed_L[0]);
    sendData(Speed_H[0]);
    
    sendData(ID[1]);
    sendData(Position_L[1]);
    sendData(Position_H[1]);
    sendData(Speed_L[1]);
    sendData(Speed_H[1]);
    
    sendData(ID[2]);
    sendData(Position_L[2]);
    sendData(Position_H[2]);
    sendData(Speed_L[2]);
    sendData(Speed_H[2]);
    
    sendData(ID[3]);
    sendData(Position_L[3]);
    sendData(Position_H[3]);
    sendData(Speed_L[3]);
    sendData(Speed_H[3]);
        
    sendData(ID[4]);
    sendData(Position_L[4]);
    sendData(Position_H[4]);
    sendData(Speed_L[4]);
    sendData(Speed_H[4]);  
      
    sendData(ID[5]);
    sendData(Position_L[5]);
    sendData(Position_H[5]);
    sendData(Speed_L[5]);
    sendData(Speed_H[5]); 
       
    sendData(ID[6]);
    sendData(Position_L[6]);
    sendData(Position_H[6]);
    sendData(Speed_L[6]);
    sendData(Speed_H[6]);    
    
    sendData(ID[7]);
    sendData(Position_L[7]);
    sendData(Position_H[7]);
    sendData(Speed_L[7]);
    sendData(Speed_H[7]);        
 
    sendData(Checksum);
}

[jwatte]

The AWG22 wires in the Dynamixel series cannot carry an infinite amount of current. Strands longer than 4 servos are not recommended.
Instead, get a high-quality hub (I make my own; and the Trossen ones are higher quality than the Robotis ones) and inject power at the center of a "star" to reduce daisy-chain current losses.

[zhanginou]

Thanks for your reply.

Do you mean this?: http://www.trossenrobotics.com/6-port-ax-mx-power-hub

[jwatte]

If you're not building your own, yes, that's the one I'd recommend!

[zhanginou]

Alright, I just ordered it, will post the results once it arrives.

Aside from that, would you happen to know why some servos' ID reset when too many are daisy-chained together?

EDIT:
Also, do you think it could also be a voltage drop problem due to too many servos chained together? I checked and the resistance of a Dynamixel AX-12a is 6ohm, and each servos draws around 300mA, so the voltage drop in each branch should be something around 1.8V. For the record the LiPo battery I am using is 11.1V but when I fully charge it it's actually 12.6V. In any case the minimum operating voltage is like 9V right, so it should be fine right?

[tician]

Last I heard, the consensus as to the cause of resetting IDs is that a brown-out (undervoltage) event due to overtaxing the power supply and/or wiring issues causes the servo to reboot and temporarily enter its bootloader. In bootloader mode, the servo only understands certain 'firmware update' messages at a specific baudrate, so any dynamixel packet is treated as garbage from a failed firmware update that triggers the servo to reset most of its internal registers to their default values.

The two molex connectors of dynamixel servos are internally bonded by small gauge wires (maybe 24AWG), but the current through the internal wires is the sum of all downstream servos on the chain so the voltage drop grows significantly larger with every servo added in the chain.

[zhanginou]

Hey tician, thanks for replying.

Is there any way apart from reducing the length of the cables, to prevent the voltage drop?

[tician]

When using the larger servos (MX-64 and MX-106), it is not uncommon for people to create a custom wiring harness using heavier gauge wire (standard cables are 22~20AWG; trossen cables are 20AWG) to power multiple hubs or to have the standard cables directly spliced into the heavier wire. Often the servos experiencing the heaviest loading are directly connected to the heavy gauge main power buss like leaves on a branch instead of chaining the servos together.

[KurtEck]

You mention using a Teensy 3.6, which is great board, but I am not sure if you at all mentioned, how your hardware is setup.

Note: There have been a few different thoughts on what causes these servos to reset like that. As mentioned the number one theory is that it is the brown out of the servos as mentioned above. Some other theories include:

The TTL level signal was not strong enough and would be corrupted. That is if the signal dropped to a low enough voltage, the voltage for a high value may not be high enough to register as a high... More about this in regards to Teensy. As I mention below I can not directly attribute the servo resetting to ID #1 to this, but it could be possibility.

Another possibility, is that the communications is not being done cleanly. In particular with the timing of the signals. I did run into this earlier on when using an Arbotix Board and at that times released code. The code did not properly know when a packet was completely sent out before it would switch back to RX mode and some of the packet could be trashed. Also at times the code did not properly wait until a servo might respond to a packet before it tried to send out another packet, and then you had both the Arbotix and the Servo trying to output at same time, which corrupted the data on the buss... I used to get a lot more servo resets back then.

Back to Teensy and 3.3v signals:

That is are you directly using the 3.3v output of a digital usart of the Teensy to drive the servo signals? Are you connected just to the TX pin of the usart and using the built in support for half duplex or doing it some other way?

I have done it using just the Teensy 3.3v output and did not end up with any issues that I could directly attribute to it. But decided later just to be safe to use something like a buffer or transistors to up the voltage to 5v.

There was a user up on the PJRC forums who stated that you don't need no stinking buffer chips I don't necessarily agree with him, but if you are not using using a buffer, you might take a look. If I remember correctly he would change the TTL drive strength of the Teensy output pin to make a stronger 3.3v output. The thread is: https://forum.pjrc.com/threads/33427...ight=dynamixel

Note: disregard that Elmue confuses TTL level servos as being RS485.

[Brooks]

Ditto what Tician said about wiring harnesses! I make mine from 14 ga solid copper house wiring, and my feed from battery to this harness is always at least 14 ga.

The 1 Mb data signal is noise sensitive. These days I use a 74AHCT125 to buffer both Tx and Rx, and clamping diodes (with local caps) to control ringing. And you really want the signal to be able to rise to +5, not just 3.3. Looking at an un-clamped signal with an oscilloscope was a real eye-opener - you could see the signal change shape just by clamping your fingers around the signal wire.

I use Teensy 3.5's for their 5v capabilities. And using the Teensy's DMA capabilities REALLY offloads the I/O load from the CPU.

These steps solved my servo-access issues. If I ever have further issues I'm going to:
1) Run both +12 down each leg using heavier wire, and splice at each servo
2) Run +5 down each leg (or put a small +5 regulator at each foot), placing clamping diodes at the last servo of each leg
3) JWatte's idea: Place (big) filter caps at the last servo of each leg. The servos create lots of power spikes.
4) KurtEck's idea: Don't use servo ID 1. Automatically renumbering a servo if you find it has moved itself to ID 1.