1. Neuron
Join Date
May 2016
Location
USA
Posts
145
Images
12
Rep Power
22

## synchronizing Dynamixel movements

The scenario is that you have multiple Dynamixels that you want to move some angular distance, and you want them to arrive at their goal at the same time. It looks like to do this, you have to calculate the speed in addition to the goal position. And of course the Dynamixels could be of different types with different speeds.

Assuming this is the correct approach, the first problem is arriving at accurate speed values for each Dynamixel type. Here are some numbers from the documentation:

AX-12

The specs list no load speed:

• No load speed : 59rpm (at 12V)

Moving Speed documentation:

• If it is 1023, it is about 114rpm.

MX-28

• 50rpm (at 11.1V)
• 55rpm (at 12V)
• 67rpm (at 14.8V)

Moving Speed documentation:

• If it is 1023, it is about 117.07rpm.

MX-64

• 58rpm (at 11.1V)
• 63rpm (at 12V)
• 78rpm (at 14.8V)

Moving Speed documentation:

• If it is 1023, it is about 117.07rpm.

The numbers from the documentation make no sense to me, and I don't think they can be relied upon. What numbers are you all using? Are you testing and measuring it yourself?

Once the speed calculation is sorted out, then the next problem is deciding how to write the values to the control table. It's probably not a coincidence that Goal Position and Moving Speed are adjacent in the table, which is nice.

There are at least three different approaches I can think of:

1. Send a WRITE DATA command to each joint, setting the goal position and moving speed. Since it should happen in several milliseconds, it may be acceptable to just do it this way. However, while simple, this approach is sub-optimal, and I would think most people are not doing things this way because the joints will start moving at different times, and the more joints the longer the time between when the first and last starts.
2. Send REG WRITE commands to each joint, then broadcast an ACTION command. With this approach, you should be able to "queue up" the next set of positions in the register and then send an ACTION with the previous movement completes (assuming it works that way, I have not tested it yet).
3. Send a single SYNC WRITE instruction containing all joint speed/position values to the broadcast address. This option seems like it could be the fastest, but it should not really be that much different than 2 in practice. Since the ACTION and SYNC WRITE are both broadcasts, all joints should start moving about the same time in both cases.

I'm interested in hearing which approach you think is the best or if one is considered a best practice.

The final concern is knowing when the previous movement has stopped so that you can start the next movement in the sequence.

Here are two approaches off the top of my head:

1. Using the speed calculation and travel distance for a joint, you can calculate how long it will take. The risk is the speed estimate has to be accurate. If it is too high, you will cut off the movement before it completes. If it is too low, there will be a pause between movements.
2. Poll the Dynamixel Moving value (address 46). With this approach, (if it works) there is no chance of cutting off movement before it completes. The pause time between movements should be ~1.5x the poll interval. Should be able to keep it to a few ms. The risk here is that I don't understand the conditions under which the Dynamixel reports as no longer moving. Documentation says "Goal position command execution is completed." Is it just that the present position is no longer changing (for how long?) Does it matter if it could not reach the goal position?

2. ## Re: synchronizing Dynamixel movements

The numbers from the documentation make no sense to me
Why? The "117 rpm" value tells you how to convert from the value in the register (0 .. 1023) to actual RPM value.
So, you calculate the actual value as (register * 117.07 / 1023) for the MX series, and (register * 114 / 1023) for the AX.

Yes, this means you can ask the servo to move faster than it is physically capable of doing on its own.
The PID controller will use the speed you configure to figure out how hard to drive the motor, and forces other than the servo may be acting upon the horn, so a higher-than-maximum value may still find uses in some cases.

3. Neuron
Join Date
May 2016
Location
USA
Posts
145
Images
12
Rep Power
22

## Re: synchronizing Dynamixel movements

Because the specs list a "no load" speed that is a lot lower than the speeds you are quoting from the Moving Speed section of the documentation. Also, the speeds in specs are qualified with a voltage whereas the Moving Speed section just has one number. The documentation is as clear as mud.

4. ## Re: synchronizing Dynamixel movements

Hi.

Speed control vs interpolation has been discussed several times. Speed control is fairly accurate under no load. But stops there. I believe Kurt tried using speed for a timed move control. Check this thead http://forums.trossenrobotics.com/sh...ighlight=Speed

5. Neuron
Join Date
May 2016
Location
USA
Posts
145
Images
12
Rep Power
22

6. T-1000
Join Date
Feb 2009
Posts
2,319
Images
2
Rep Power
138

## Re: synchronizing Dynamixel movements

Simple summary: I punted! At least with the AX Servos I never found a reliable way to make speed control to work. I believe Kevin had some luck.

So I went back to the way Arbotix library works and do my own interpolation and speed control. The concept is pretty simple:

You wish for N servos to move from current position to a new position in so much time. So you define some arbitrary time frame length like 10ms, which implies you have 100 updates per second.

You then calculate how many time periods are contained in your move. Suppose your move should complete in 50ms. That would imply that you have 5 time slices (50ms/10ms).

So if one of your servos wants to move from position 400 to 600 in this time frame, then you need to add 40 units = (600-400)/5 for each time period... Can work the same for MX servos, the only differences are in resolution and zero point. So if your code works with angles, then your code needs to know AX/MX to be able to convert angles into servo units.

As I mentioned in some other postings, with my own servo controllers, I will try to move a bunch of these types of details into the servo controller.

7. ## Re: synchronizing Dynamixel movements

I tried and tried to get it to accurately work. It just would not work in all cases needed for smooth locomotion, so I punted as well. It is far easier and cleaner to do it the interpolation way.

8. ## Re: synchronizing Dynamixel movements

a "no load" speed that is a lot lower than the speeds you are quoting from the Moving Speed section of the documentation.
Yes. I thought I just explained that.

The maximum value of the register is a mathematical construct. The actual value you can achieve depends on load on the servo.

The maximum value in the register expresses what you can ask for. The load/speed table expresses what you can actually achieve. These are different quantities.

9. Neuron
Join Date
May 2016
Location
USA
Posts
145
Images
12
Rep Power
22

## Re: synchronizing Dynamixel movements

Ok. That explanation is so unintuitive that my brain rejected it, I suppose.

I did my own little speed test on the AX, and to travel 300 degrees under no load takes 1443 ms or 1.43 seconds (4.81 ms/degree). The timing is very consistent to the ms.

[On side note, RPM per unit is a really odd metric.]

I'll play around with the interpolation concept when I get some time this weekend. It still kind of begs the question though:

Suppose your move should complete in 50ms.
How do you know how long it should take to complete? That's a function of the distance and speed. I'll probably put some load on the actuator and do a speed test, then use that to fudge the time variable, erring a little on the slower side. As always your thoughts are welcome.

10. ## Re: synchronizing Dynamixel movements

Actually, it's true that having synchronized and reliable movements in the face of unknown load conditions is a currently a challenge.
That could be something where interpolation+feedback loop to keep all servos moving together could make a difference... and that in turn requires fast read and write... (wink wink)

Anyway, for your last question: it depends on your goal, but testing different values in the worste case scenario until you get something that works reasonably well is probably the way to go...
You can't really compute it without a decent model of the servo and of the loads that it will see, both of which are very far away from simple.

There are currently 1 users browsing this thread. (0 members and 1 guests)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•