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

## walking robot prototyping

I'm starting this thread to share what I'm learning (and get help) as I prototype for what will eventually become a walking robot (or three). I'm planning to start a blog where I'll get into an excruciating level of detail on this stuff, will share that later for those who may be interested.

I'm want to briefly share what I've learned about how Moving Speed works on the AX-12. I did this initial round of testing on an AX-12A.

Here is an image of what the AX-12A speeds are in degrees/second (y axis) by address (x axis). I only went up to 600 because the speed stays flat up to 1023.

Moving Speed is interesting. First, it's non-linear, probably logarithmic. Second, it's blocky. The fastest speed covers almost half of the addresses, then the next fastest speeds are discrete values, 90% of max, then 82%, 75%, etc. The faster speeds take up large address blocks, which get smaller as it slows down. The most interesting thing is that the faster speed blocks have these spikes in the middle of them. The spikes are always to the next faster speed, until the slowest two, where it's the next slower speed. The spikes stop after about 40% of max. Very odd.

The existence of these spikes means that you can't calculate your speed then write a function to get the appropriate address, because you might land on a spike. The spikes do occur at predictable address though, so for the speeds above 40% of max, you can pick an address in the middle of the flat part of the block for that speed.

I wrote a function to do speed-based movement synchronization, and it seems to work fairly well. I found that the easiest way to deal with these values is to make it percent based. I basically created a table (an array) with a Moving Speed address value for each percent (whole numbers from 0 to 100). So you give the function your array of joint data, and it figures out how far each is going to move, calculates speed percentages for each, then looks up the Moving Speed address value to set for that joint. You can also give it a "relative" max speed, and it does the math to find the correct percentages from the "absolute" max speed. You never deal with actual speeds, instead converting from percentages to Moving Speed addresses.

Also, in case anyone didn't realize this, the default speed (address 0) is not the fastest speed. It's actually the third fastest speed (~82% of max). The documentation states: "If it is set to 0, it means the maximum rpm of the motor is used without controlling the speed."

Of course the application of this approach is theoretical, no idea how well it would hold up on a real robot. Interpolation may very well still be the way to go.

I'm also very curious to see how the MX-64 compares, will get to that later though.
Last edited by _ADAM_; 05-24-2016 at 10:13 PM.

2. ## Re: walking robot prototyping

Very interesting indeed. The spikes where really odd, but I assume there is a logic explanation.?
Did you test your speed-based movement sync under load too? If I recall correctly the torque decreases considerably at lower speed. Or does your algorithm compensate speed if the moving speed doesn't match the target speed?

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

## Re: walking robot prototyping

Originally Posted by Zenta
The spikes where really odd, but I assume there is a logic explanation.?
Maybe tician, jwatte, kurt or xevel will have some insight.

Originally Posted by Zenta
Did you test your speed-based movement sync under load too? If I recall correctly the torque decreases considerably at lower speed. Or does your algorithm compensate speed if the moving speed doesn't match the target speed?
Not yet, but I will. I started to set it up, may get to it tonight. The plan is to spot check to see if the address/speed ratios hold up under load. I also want to confirm if the boundaries of the "blocks" and address spans of "spikes" stay the same. If all of these things don't hold true, then I too will punt on this exercise.

I'll also do a little testing on an AX-12+ and see if it's the same.

4. ## Re: walking robot prototyping

The overall shape of the curve probably has an implementation explanation.

First, the fact that 600-1024 are "flat" means that you can ask for a faster speed than the servo motor+gearbox+driver is capable of delivering. This is not particularly unexpected, and might even be useful -- if something is helping you along (such as a spring) then you could conceivably modulate the speed at a rate faster than the fastest unloaded speed.

The fact that it gets a bit flatter on the right is not "logarithmic" but probably has to do with diminishing returns in the driver circuitry.

The discrete steps might have to do with the physical resolution of the ADC that reads position, as well as the PWM quantization in the driver. Speed is calculated by reading the potentiometer at a certain rate, and subtracting one position from the previous, dividing by time. The ADC gives, at best, 10 bits of resolution, meaning 1024 separate steps, which means that at the very bottom, you may not be seeing one step movement per control cycle tick. At the high end, you may be seeing a fine amount of changes, but you are instead limited by the bandwidth of your controller and quantization of your PWM output.
Or it's experimental error or measurement error or one of a host of other possible errors...

Ths "spikes?" Either a bug in the firmware, or some emergent property of the system and control algorithms, where certain values end up dividing/quantizing more favorably than others. If you look at the peak of the "spikes," and fit a line to them, they look like the most linear part of this graph, so it may be that those spikes are the values at which the system physically matches the theory the best, whereas in the lower/dippy parts, various physical/electrical imperfections makes the system work less well than theoretically specified. This is speculation, of course.
Again, there are a number of possible other errors that can contribute to that graph.

What was your experimental setup? Camera based? "Servo tester" based? A quadrature encoder on the output shaft?
I'd love to see some pictures or a block diagram.

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

## Re: walking robot prototyping

Again sounds like you are having some fun here and I will follow along, to see what you come up with.

As I mentioned, I am so far going a different route. That is I am using Software interpolation and will again hopefully push most of this into the servo controller. Had a version of USB2AX firmware before that did some of this. But this time around will probably do it mainly with other hardware like Teensy boards running Arduino sketch. Will talk more about this in appropriate thread.

Kurt

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

## Re: walking robot prototyping

Originally Posted by jwatte
The overall shape of the curve probably has an implementation explanation.

First, the fact that 600-1024 are "flat" means that you can ask for a faster speed than the servo motor+gearbox+driver is capable of delivering. This is not particularly unexpected, and might even be useful -- if something is helping you along (such as a spring) then you could conceivably modulate the speed at a rate faster than the fastest unloaded speed.

The fact that it gets a bit flatter on the right is not "logarithmic" but probably has to do with diminishing returns in the driver circuitry.

The discrete steps might have to do with the physical resolution of the ADC that reads position, as well as the PWM quantization in the driver. Speed is calculated by reading the potentiometer at a certain rate, and subtracting one position from the previous, dividing by time. The ADC gives, at best, 10 bits of resolution, meaning 1024 separate steps, which means that at the very bottom, you may not be seeing one step movement per control cycle tick. At the high end, you may be seeing a fine amount of changes, but you are instead limited by the bandwidth of your controller and quantization of your PWM output.
Or it's experimental error or measurement error or one of a host of other possible errors...

Ths "spikes?" Either a bug in the firmware, or some emergent property of the system and control algorithms, where certain values end up dividing/quantizing more favorably than others. If you look at the peak of the "spikes," and fit a line to them, they look like the most linear part of this graph, so it may be that those spikes are the values at which the system physically matches the theory the best, whereas in the lower/dippy parts, various physical/electrical imperfections makes the system work less well than theoretically specified. This is speculation, of course.
Again, there are a number of possible other errors that can contribute to that graph.

What was your experimental setup? Camera based? "Servo tester" based? A quadrature encoder on the output shaft?
I'd love to see some pictures or a block diagram.
I agree that the flat part above 600 appears to be because the servo doesn't operate in that speed range. The fastest speed should end around 600, but it continues all the way to 1023.

It's hard to tell from the graph, but it is logarithmic or some approximation thereof. It's not linear at any point, not even the lowest addresses. The speed increase from address to address is always getting bigger. I can link the spreadsheets if anyone is interested.

My setup isn't hardware, it's software. I wrote a little driver to move the actuator through it's full range of motion at all 1024 Moving Speed values and logged the time each takes, then converted that to degrees/second and also a % of the max speed.

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

## Re: walking robot prototyping

Originally Posted by KurtEck
Again sounds like you are having some fun here and I will follow along, to see what you come up with.
Thanks, yes it is fun. Slow but steady progress that will hopefully lead to some cool stuff.

Originally Posted by KurtEck
As I mentioned, I am so far going a different route. That is I am using Software interpolation and will again hopefully push most of this into the servo controller. Had a version of USB2AX firmware before that did some of this. But this time around will probably do it mainly with other hardware like Teensy boards running Arduino sketch. Will talk more about this in appropriate thread.
I'm going to be doing everything in software. I'll implement interpolation as well when I feel like I completely understand Moving Speed. I think what I learned will also help with refining the interpolation algorithm since I should now be equipped to estimate how long a move will take.

8. ## Re: walking robot prototyping

It's hard to tell from the graph, but it is logarithmic or some approximation thereof
I don't think we agree on what "logarithmic" means then. I think a correlation with a straight line would be very high. It may be some root (power function with an exponent slightly less than 1) but that root will be for a value significantly closer to 1 than 2.

My setup isn't hardware, it's software.
Ah! In that case, it is possible that the various artifacts you see may also be caused by interactions between the control algorithm and the position-reading code.

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

## Re: walking robot prototyping

Originally Posted by jwatte
Ah! In that case, it is possible that the various artifacts you see may also be caused by interactions between the control algorithm and the position-reading code.
I think you are talking about the code running on the chip in the Dynamixel? But yeah, whatever is happening is happening down there.

What I'm saying may already be clear, but just in case here is a chunk of data for the ~53% speed. Columns are address, speed (degrees/sec), time ms, % of max speed.

This block of addresses 245 - 261 make the servo move at a certain speed: ~2230 ms to travel 300 degrees....except that 250-252 (the spike) is the next faster speed, taking ~2100 ms to travel 300 degrees. The speeds are consistent and repeatable within a ms or two. Very precise considering the long distance traveled.

Code:
```245
134.53
2230
52.96%

246
134.53
2230
52.96%

247
134.53
2230
52.96%

248
134.53
2230
52.96%

249
134.53
2230
52.96%

250
142.93
2099
56.26%

251
142.93
2099
56.26%

252
142.93
2099
56.26%

253
134.53
2230
52.96%

254
134.53
2230
52.96%

255
134.53
2230
52.96%

256
134.53
2230
52.96%

257
134.53
2230
52.96%

258
134.53
2230
52.96%

259
134.53
2230
52.96%

260
134.53
2230
52.96%

261
134.53
2230
52.96%

```
There is a little variability in the exact boundaries of the blocks, but it never varies by more than an address. There is definitely something "fuzzy" in how the actuator reckons which speed to pick for a particular address, but it always fits the observed pattern. For example, the fastest speed might end at address 527 most of the time, but sometimes it might end at 528. Same thing with the spikes, they are always in the same spot. It might usually be 3 addresses, but sometimes it will be 4, but in the same range (i.e. 250-252 becomes 250-253).

10. ## Re: walking robot prototyping

What would be interesting is to study both target speed and current speed individually compared to actual, externally recorded speed. Otherwise you're looking at two layers of stuff happening and it's not as easy to understand.

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