Results 1 to 10 of 10

Thread: walking robot prototyping

  1. #1
    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. #2
    Join Date
    Jan 2008
    Location
    Norway, Stavanger
    Posts
    790
    Images
    276
    Rep Power
    86

    Re: walking robot prototyping

    Hi Adam,

    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?
    Kåre Halvorsen aka Zenta
    ---------------------------------
    Zenta's YouTube channel
    Zenta's Blog
    Zenta's Instagram

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

    Re: walking robot prototyping

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

    Quote Originally Posted by Zenta View Post
    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. #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. #5

    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. #6
    Join Date
    May 2016
    Location
    USA
    Posts
    145
    Images
    12
    Rep Power
    22

    Re: walking robot prototyping

    Quote Originally Posted by jwatte View Post
    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. #7
    Join Date
    May 2016
    Location
    USA
    Posts
    145
    Images
    12
    Rep Power
    22

    Re: walking robot prototyping

    Quote Originally Posted by KurtEck View Post
    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.

    Quote Originally Posted by KurtEck View Post
    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. #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. #9
    Join Date
    May 2016
    Location
    USA
    Posts
    145
    Images
    12
    Rep Power
    22

    Re: walking robot prototyping

    Quote Originally Posted by jwatte View Post
    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.
    ---
    Personal blog: http://xevel.org
    USB2AX documentation: http://xevelabs.com

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Contest Entry Walking CNC Router Robot
    By mdenton in forum Project Showcase
    Replies: 14
    Last Post: 09-06-2010, 04:27 AM
  2. Question(s) Sheet Metal Prototyping
    By bonmot in forum Robotics General Discussion
    Replies: 25
    Last Post: 03-10-2010, 07:48 PM
  3. 2010 Scoring System Prototyping
    By lnxfergy in forum Mech Warfare
    Replies: 8
    Last Post: 12-07-2009, 06:20 PM
  4. Good Entry level 3d cad prototyping tool
    By Nelsontheunholy in forum Software and Programming
    Replies: 10
    Last Post: 10-19-2009, 03:49 PM
  5. Project Hand soldering, building, prototyping
    By LinuxGuy in forum Arbotix, Microcontrollers, Arduino
    Replies: 2
    Last Post: 05-22-2008, 03:14 PM

Tags for this Thread

Posting Permissions

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