PDA

View Full Version : [Project] It's ALIVE!



tigakub
05-20-2015, 03:30 AM
My first robot walks for the first time today! It's pretty rudimentary still, but I'm pretty happy with the movement considering its my first attempt.

At the moment, the legs are a bit ungainly. The distals are a bit too long. I'd originally intended each limb to have 4 dof, but decided the power costs and programming complexity weren't worth the extra dof. I've redesigned them and am waiting for Shapeways to finish printing them. The new ones will be shorter and have receptacles to which I will attach rubber feet.

I still have to attach a battery for improved autonomy, and I hope to ditch the ArbotiX in favor of an Edison.


http://www.youtube.com/watch?v=9N0FXJdi8cc

jwatte
05-20-2015, 11:03 AM
Those legs look pretty cool when it's scrunched together, though :-)
Are you using Nuke or your own code?

tigakub
05-20-2015, 01:33 PM
Those legs look pretty cool when it's scrunched together, though :-)

Thanks! The redesign will be similar, just not as long. And, as you can see in the video, the pointy tips have poor traction.


Are you using Nuke or your own code?

I'm calling into the ax library on the ArbotiX to interface with the servos, but the rest is home brewed ... reinventing the wheel, but I want to learn.

jwatte
05-20-2015, 09:08 PM
as you can see in the video, the pointy tips have poor traction

Are you doing IK? If not, the slipping may be simply because the feet don't move exactly straigt compared to the body/ground.


reinventing the wheel, but I want to learn

I wrote my own IK/walking too. Not a bad way to go :-)

Zenta
05-21-2015, 08:21 AM
Nice work! Looks beautiful when it lower the body and the legs folds like a half sphere. The rather long tibias might be a problem in some cases though, like the need of expanding the initial leg positions.

Keep up the good work!

tigakub
05-21-2015, 09:13 PM
Are you doing IK?

Yes, I am. I have to say I'm pretty impressed with the Arbotix. It's computing the IK on 6 limbs at 20 Hz, and the only reason it isn't going at 30 Hz is that the ax12a bus seems to saturate even though I'm sync writing. 20 Hz is still not as smooth as I'd like. Does anyone have a suggestion as to how I might reduce latency on the Dynamixel bus? Or is the solution to go with more advanced servos?


Nice work! Looks beautiful when it lower the body and the legs folds like a half sphere. The rather long tibias might be a problem in some cases though, like the need of expanding the initial leg positions.

Keep up the good work!

Thanks, Zenta. You are correct about the length of the tibia. I'd originally intended there to be 4 servos per limb, and the longer tibias made more sense. But I got concerned about the power requirements for 24 servos, as well as update frequency. After actually seeing the thing in operation, it's become apparent that shorter limbs would make for more stability, not to mention less strain on the servos.

KevinO
05-21-2015, 09:34 PM
I'd originally intended there to be 4 servos per limb, and the longer tibias made more sense. But I got concerned about the power requirements for 24 servos, as well as update frequency. After actually seeing the thing in operation, it's become apparent that shorter limbs would make for more stability, not to mention less strain on the servos.

You can run 24 easily. I had a 4dof version of the phantomX a couple of years ago and it wasn't an issue.


https://www.youtube.com/watch?v=Ywg8VOPoiH4

tician
05-21-2015, 10:27 PM
The darwin-op/nimbro-op/hr-os1/5 frameworks easily push goal positions to 20+ servos at 125Hz at 1Mbps with sync-write and no servo feedback using an embedded-PC for IK and packet building and FTDI+STM32 (cm-730 or arbotix-pro) for pushing the packets to the bus. If there is not a long timeout or latency somewhere in the arbotix ax12 library or your code, then it is possible that the arbotix is just too slow to handle everything running at its measly 16MHz.

tigakub
05-22-2015, 01:21 AM
Oops. Looks like I might have toasted my ArbotiX. Doh. I was trying to do a bit of simple profiling to see how much time was spent calculating the IK solution, and I guess it didn't like the way I was doing things cuz when I plugged it back in ... nothing. Guess it's over to the ArbotiX forum to see if Kyle or someone else at Trodden has any opinions.

Before it went out, I was able to bump the update frequency to 30 Hz, so I guess the difficulties I was having before was due to something else, not saturation of the bus as ticain and Kevin suggest.

tigakub
06-13-2015, 06:19 PM
UPDATE. Got my new ArbotiX, new tibias, and completely rewrote the sketch. Now the the IK and gait control are done 100% on the ArbotiX. I did a bit of profiling, and even with floating point matrix math, the IK goal transformations, and IK/FK calculations are taking about 25 ms (+/- 3ms). Slow, but good enough for pretty smooth interpolation.

6029


https://youtu.be/qOTtPviXGuU

KevinO
06-13-2015, 09:23 PM
Looks great! Well done!

tician
06-13-2015, 09:39 PM
Quite cool. Even after Zenta's MorpHex, I'm still not used to seeing bots intentionally twist up into a little ball; too many experiences with crushed fingers and falling robots from unintentional twisting into a little ball and/or trying to kick the back of its own head...

I'm not so sure about having the LiPo hanging under the bot without full length plates and standoffs to help protect it should the bot trip/fall/drop. Just seems like a recipe for bending/puncturing the cells and torching the pack/bot as it looks a lot like half of a single shear strength testing rig.

tigakub
06-14-2015, 12:25 AM
Quite cool. Even after Zenta's MorpHex, I'm still not used to seeing bots intentionally twist up into a little ball; too many experiences with crushed fingers and falling robots from unintentional twisting into a little ball and/or trying to kick the back of its own head...

Lol. I'm only using AX12A's for this bot so even if I got my finger caught, I don't think I'm in danger of loosing it. But I have to say that when I first did get pinched by one, I was surprised how much it hurt. Errant limb movements are how I destroyed an FTDI module.


I'm not so sure about having the LiPo hanging under the bot without full length plates and standoffs to help protect it should the bot trip/fall/drop. Just seems like a recipe for bending/puncturing the cells and torching the pack/bot as it looks a lot like half of a single shear strength testing rig.

Agreed. I designed the brackets with an entirely different configuration in mind, where the battery would actually be placed vertically up through the center of the hexagonal frame. But when it became apparent that the ArbotiX wouldn't really be powerful enough to do everything I wanted to, I decided to scale things back. There isn't really any formal receptacle for the battery. It's just clamped on for testing purposes. I think I'm not going to design a retrofit enclosure, but redesign the body frame so that I can embed the battery, as well as mount a larger, more powerful controller, like the RPi, Jetson or NUC.

tigakub
06-14-2015, 02:45 AM
I remember reading in another thread about someone trying to use the Dynamixel's load measurement capability, but for the life of me I can't find it again.

I did some experimentation today on that front. Here's a video of the result:


https://www.youtube.com/watch?v=k52OtakF0Sw

It doesn't work so well while the bot is walking though. I've found the telemetry so noisy that I have to smooth it really heavily. I'd love to compare notes with anyone else who's tried (successfully or not) to use the load telemetry for the purpose of adapting to uneven terrain.

tician
06-14-2015, 03:27 AM
One of those threads was r3n33's hexapod (http://forums.trossenrobotics.com/showthread.php?7411-ROS-enabled-PhantomX-Hexapod/page4), but I'm quite certain there are others on the forum that are 2+ years old.

The 'CURRENT_LOAD' value is the PWM-value used by the ATmega88 to drive the H-bridge, so does not necessarily represent a 'real-world' value (current through the motor/H-bridge will vary with battery voltage / charge state; no guaranteed relationship between PWM-value and motor current/torque). Have to go up to the MX-64 and MX-106 to get an actual current sensor (power resistor? actual hall-effect current sensor?), and I'm thinking you have to upgrade to the Dynamixel Pro have actual torque sensors but not certain that even they have them.

There are multiple ways to make your own torque sensors that add varying amounts of compliance to the joint: my two favorites are 'low cost arm' route with urethane tubing between laser-cut disks linking cable/belt drive system to actual joint, and the milled metal spiral with 'sloped flag' and analog optointerruptor sensor to measure how much the spiral is rotating/deforming under load. Both measure the rotational difference between adjacent disks or inner and outer rings, respectively, and use the material properties of the urethane or metal to estimate the torque achieving that rotational difference.

tigakub
06-14-2015, 06:42 PM
Looks great! Well done!

Oops. Didn't mean to be rude. Missed your post. Thanks!

tigakub
06-14-2015, 06:58 PM
One of those threads was r3n33's hexapod (http://forums.trossenrobotics.com/showthread.php?7411-ROS-enabled-PhantomX-Hexapod/page4), but I'm quite certain there are others on the forum that are 2+ years old.

Yes! That's exactly the one. Thanks for the link!


The 'CURRENT_LOAD' value is the PWM-value used by the ATmega88 to drive the H-bridge, so does not necessarily represent a 'real-world' value (current through the motor/H-bridge will vary with battery voltage / charge state; no guaranteed relationship between PWM-value and motor current/torque). Have to go up to the MX-64 and MX-106 to get an actual current sensor (power resistor? actual hall-effect current sensor?), and I'm thinking you have to upgrade to the Dynamixel Pro have actual torque sensors but not certain that even they have them.

Hmmm, ok. I knew that it wasn't really an accurate measure of load, but I hadn't even considered whether it was stable over the life-time of the power supply. I wonder if the voltage data can be used to compensate for drift in the load? I guess the only way to find out would be to do some tests.


There are multiple ways to make your own torque sensors that add varying amounts of compliance to the joint: my two favorites are 'low cost arm' route with urethane tubing between laser-cut disks linking cable/belt drive system to actual joint, and the milled metal spiral with 'sloped flag' and analog optointerruptor sensor to measure how much the spiral is rotating/deforming under load. Both measure the rotational difference between adjacent disks or inner and outer rings, respectively, and use the material properties of the urethane or metal to estimate the torque achieving that rotational difference.

Yeah, I guess, given how noisy the current load data is, a proper solution would have to be dedicated sensors.

r3n33
06-14-2015, 07:46 PM
Oh wow! That video of the adaptive load balancing is great! If you continue to work on that I'd love to see more. Oh and I really like the look of the new tibias. What are you using for the toes?

Romain, here on the forums will really appreciate this work; I'll nudge him to make sure he doesn't miss the post since he is working on walking on uneven terrain.

Edit: I'm also interested in the noisy telemetry data. What does it look like and what have you done to smooth it?

Zenta
06-15-2015, 12:53 AM
Hi,

Wow, this is cool! I really like your load balancing / compliance test. How did you do it? Did you set the torque to about 40 -50% and then reading the positions, doing FK and then IK? I imagine it isn't that simple though. Would the hexapod have a "softer" compliance if you where able to have a higher refresh rate?

Your demo really made me enthusiastic!

The demo of the Carnegie Mellon's hexapod (https://youtu.be/fDCDewLSE6M?list=FLmCZ-oLEnCgmBs_TMql9afw) is really awesome, imagine if we could do something like that. Maybe the MX-series would perform even better for tasks like this.

tigakub
06-15-2015, 02:37 AM
Oh wow! That video of the adaptive load balancing is great! If you continue to work on that I'd love to see more.

Hah! Actually, it was your thread about your hexapod that got me started. At some point you and several others were discussing using the load data in this way. That inspired me to try it out after discovering that I had a few extra bytes and clock cycles on my ArbotiX-M. Although it looks promising in the video, because the smoothing imposes such a delay, I'm not sure that it will really prove useful during locomotion. I did try it out during gait, and I think it did help a very little bit when navigating over an obstacle, but not as much as I had hoped. My bot did seem to settle nicely when it stopped on uneven ground, though. There are a couple of other things I might try, basically things suggested by KurtEck here (http://forums.trossenrobotics.com/showthread.php?7411-ROS-enabled-PhantomX-Hexapod&p=67396#post67396), but I'm thinking that it would entail significant restructuring/rewriting of my current gait code.


Oh and I really like the look of the new tibias. What are you using for the toes?

Thanks! Shapeways is great! I just wish I didn't have to wait so long to get the results. The toes are just rubber feet I got off Amazon. Here's a link (http://www.amazon.com/gp/product/B003B0YDRM?psc=1&redirect=true&ref_=oh_aui_detailpage_o09_s01). I hope I'm not violating some code of conduct by providing a link off site.


Romain, here on the forums will really appreciate this work; I'll nudge him to make sure he doesn't miss the post since he is working on walking on uneven terrain.

It'd be great to exchange notes.


Edit: I'm also interested in the noisy telemetry data. What does it look like and what have you done to smooth it?

Oh, it's nothing very esoteric. I'm only using the load telemetry from the femur servos. It's a simple exponential average with a HEAVY bias towards the historical portion. I chose the 0.9/0.1 weighting empirically: even a 0.85/0.15 weighting resulted in a LOT of jitter. During gait, I only use the telemetry from the load bearing limbs.


loadSum = 0.0;
for each load bearing limb {
rawLoad = ax12GetRegister(femurId, AX_PRESENT_LOAD_L, 2);
scale = (rawLoad & 0x400)?-0.1:0.1;
limbLoads[limbId] = limbLoads[limbId] * 0.9 + float(rawLoad & 0x3ff) * scale;
loadSum += limbLoads[limbId];
}
loadAvg = loadSum / loadedLimbCount;


And then I calculate a compensator for each limb's IK goal based on the difference between the limb load, and the simple average of the loads. The compensation value is also heavily smoothed with a weighted average.


delta = limbLoads[limbId] - loadAvg;
loadCompensation[limbId] = loadCompensation[limbId] * 0.9 + (MAGNITUDE * delta / 1024.0) * 0.1;

Then I simply use this load compensation to offset the vertical height of the IK goal. Actually, the load telemetry is quite stable when the bot is static, but once the servos start moving, things quickly get crazy. Here's a sample of the raw data. For some reason the data from limb 0 seemed to have been clobbered by the logging, but you can get an idea of the quality of the data.


Raw Load 0:-1, 1:1088, 2:1760, 3:1088, 4:0, 5:1088
Raw Load 0:-1, 1:1760, 2:1760, 3:1088, 4:1216, 5:1088
Raw Load 0:-1, 1:1760, 2:1760, 3:416, 4:1216, 5:136
Raw Load 0:-1, 1:400, 2:400, 3:416, 4:1216, 5:136
Raw Load 0:-1, 1:400, 2:400, 3:416, 4:24, 5:136
Raw Load 0:-1, 1:1120, 2:1040, 3:1080, 4:24, 5:1080
Raw Load 0:-1, 1:1120, 2:1040, 3:1080, 4:24, 5:1080
Raw Load 0:-1, 1:1120, 2:1040, 3:8, 4:24, 5:1112
Raw Load 0:-1, 1:112, 2:104, 3:8, 4:24, 5:1112
Raw Load 0:-1, 1:112, 2:104, 3:8, 4:1128, 5:1112
Raw Load 0:-1, 1:112, 2:104, 3:248, 4:1128, 5:16
Raw Load 0:-1, 1:1200, 2:1104, 3:248, 4:0, 5:16
Raw Load 0:-1, 1:1200, 2:1104, 3:176, 4:0, 5:1064
Raw Load 0:-1, 1:40, 2:48, 3:176, 4:0, 5:1064
Raw Load 0:-1, 1:40, 2:48, 3:176, 4:40, 5:1064
Raw Load 0:-1, 1:40, 2:48, 3:320, 4:40, 5:1088
Raw Load 0:-1, 1:1040, 2:128, 3:320, 4:1072, 5:1088
Raw Load 0:-1, 1:1040, 2:128, 3:320, 4:1072, 5:16
Raw Load 0:-1, 1:208, 2:168, 3:64, 4:1072, 5:16
Raw Load 0:-1, 1:208, 2:168, 3:64, 4:8, 5:16
Raw Load 0:-1, 1:208, 2:168, 3:128, 4:8, 5:72
Raw Load 0:-1, 1:104, 2:64, 3:128, 4:8, 5:72
Raw Load 0:-1, 1:104, 2:64, 3:128, 4:8, 5:72
Raw Load 0:-1, 1:104, 2:64, 3:184, 4:8, 5:40
Raw Load 0:-1, 1:88, 2:32, 3:184, 4:8, 5:40
Raw Load 0:-1, 1:88, 2:32, 3:184, 4:16, 5:40
Raw Load 0:-1, 1:88, 2:32, 3:256, 4:16, 5:1096
Raw Load 0:-1, 1:128, 2:136, 3:256, 4:24, 5:1096
Raw Load 0:-1, 1:128, 2:136, 3:256, 4:24, 5:80
Raw Load 0:-1, 1:184, 2:192, 3:344, 4:24, 5:80
Raw Load 0:-1, 1:184, 2:192, 3:344, 4:1144, 5:80
Raw Load 0:-1, 1:184, 2:192, 3:384, 4:1144, 5:80
Raw Load 0:-1, 1:240, 2:224, 3:384, 4:1144, 5:80
Raw Load 0:-1, 1:240, 2:224, 3:384, 4:8, 5:80
Raw Load 0:-1, 1:240, 2:224, 3:248, 4:8, 5:1088
Raw Load 0:-1, 1:328, 2:264, 3:248, 4:32, 5:1088
Raw Load 0:-1, 1:328, 2:264, 3:248, 4:32, 5:48
Raw Load 0:-1, 1:272, 2:248, 3:208, 4:32, 5:48
Raw Load 0:-1, 1:272, 2:248, 3:208, 4:1104, 5:48
Raw Load 0:-1, 1:272, 2:248, 3:288, 4:1104, 5:1032
Raw Load 0:-1, 1:96, 2:152, 3:288, 4:24, 5:1032
Raw Load 0:-1, 1:96, 2:152, 3:288, 4:24, 5:1032
Raw Load 0:-1, 1:40, 2:8, 3:272, 4:24, 5:1040
Raw Load 0:-1, 1:40, 2:8, 3:272, 4:-1, 5:1040
Raw Load 0:-1, 1:40, 2:8, 3:272, 4:1048, 5:1088
Raw Load 0:-1, 1:80, 2:32, 3:232, 4:1048, 5:1088
Raw Load 0:-1, 1:80, 2:32, 3:232, 4:1136, 5:1088
Raw Load 0:-1, 1:80, 2:32, 3:176, 4:1136, 5:1040
Raw Load 0:-1, 1:80, 2:144, 3:176, 4:1040, 5:1040
Raw Load 0:-1, 1:80, 2:144, 3:176, 4:1040, 5:1040
Raw Load 0:-1, 1:64, 2:200, 3:152, 4:1040, 5:1040
Raw Load 0:-1, 1:64, 2:200, 3:152, 4:1072, 5:1040
Raw Load 0:-1, 1:64, 2:200, 3:128, 4:1072, 5:-1
Raw Load 0:-1, 1:128, 2:96, 3:128, 4:0, 5:1032
Raw Load 0:-1, 1:128, 2:96, 3:128, 4:0, 5:1032
Raw Load 0:-1, 1:128, 2:32, 3:168, 4:0, 5:8
Raw Load 0:-1, 1:128, 2:32, 3:168, 4:1176, 5:8
Raw Load 0:-1, 1:128, 2:32, 3:168, 4:1176, 5:1104
Raw Load 0:-1, 1:96, 2:96, 3:256, 4:1176, 5:1104
Raw Load 0:-1, 1:96, 2:96, 3:256, 4:1040, 5:1104
Raw Load 0:-1, 1:96, 2:96, 3:288, 4:1040, 5:32
Raw Load 0:-1, 1:0, 2:96, 3:288, 4:1088, 5:32
Raw Load 0:-1, 1:0, 2:96, 3:288, 4:1088, 5:32
Raw Load 0:-1, 1:0, 2:152, 3:256, 4:1088, 5:1032
Raw Load 0:-1, 1:168, 2:152, 3:256, 4:1080, 5:1032
Raw Load 0:-1, 1:168, 2:152, 3:160, 4:1080, 5:1128
Raw Load 0:-1, 1:208, 2:120, 3:160, 4:1080, 5:1128
Raw Load 0:-1, 1:208, 2:120, 3:160, 4:1088, 5:1128
Raw Load 0:-1, 1:208, 2:96, 3:128, 4:1088, 5:1104
Raw Load 0:-1, 1:144, 2:96, 3:128, 4:1120, 5:1104
Raw Load 0:-1, 1:144, 2:96, 3:192, 4:1120, 5:1032
Raw Load 0:-1, 1:72, 2:96, 3:192, 4:1120, 5:1032
Raw Load 0:-1, 1:72, 2:96, 3:192, 4:8, 5:1032
Raw Load 0:-1, 1:72, 2:96, 3:256, 4:8, 5:0
Raw Load 0:-1, 1:80, 2:96, 3:256, 4:1128, 5:0
Raw Load 0:-1, 1:80, 2:96, 3:256, 4:1128, 5:1112
Raw Load 0:-1, 1:96, 2:160, 3:288, 4:1128, 5:1112
Raw Load 0:-1, 1:96, 2:160, 3:288, 4:8, 5:1112
Raw Load 0:-1, 1:96, 2:160, 3:224, 4:8, 5:1080
Raw Load 0:-1, 1:128, 2:128, 3:224, 4:8, 5:1080
Raw Load 0:-1, 1:128, 2:128, 3:224, 4:1088, 5:1080

Any Bladerunner fans here? Imagine Pris after Decker shoots her. That's how my bot behaved without the smoothing.


https://www.youtube.com/watch?v=e9t5ikxjAQ4

tigakub
06-15-2015, 03:16 AM
Wow, this is cool! I really like your load balancing / compliance test. How did you do it? Did you set the torque to about 40 -50% and then reading the positions, doing FK and then IK? I imagine it isn't that simple though. Would the hexapod have a "softer" compliance if you where able to have a higher refresh rate?

Your demo really made me enthusiastic!

Thanks, Zenta! I didn't change the torque or torque-limit. I just thought that the more resolution I could get, the better, but come to think about it, maybe less sensitivity would be better here. Seriously, I have no idea what I'm doing, just trying random stuff that catches my interest. As I explained in my previous post, I'm just using deviation from a norm to adjust the y-component of each ik goal. The "compliance" was not deliberate, but just emergent behavior. At the moment I'm only using the load telemetry from the femurs, but you're giving me the idea to use the tibias for lateral compliance.


The demo of the Carnegie Mellon's hexapod (https://youtu.be/fDCDewLSE6M?list=FLmCZ-oLEnCgmBs_TMql9afw) is really awesome, imagine if we could do something like that. Maybe the MX-series would perform even better for tasks like this.

I know, right?!? Those are custom built servos, right? Must be. I am seriously considering investing in a few of the more advanced Dynamixels to see how much can be accomplished with just mucking around with the load telemetry. Do you know for sure if the MX or RX servos feature dedicated/stable torque sensors? Reading the manual for the MX doesn't seem to indicate they do. Ultimately, however, I think that, as tician suggests, it's going to take some dedicated sensors to reliably and efficiently detect ground impact. I don't know, would a simple binary contact switch for each foot suffice? Or would I really need accurate torque sensors? I've been trying to dig up articles on how Boston Dynamics deals with ground impact detection, but I'm thinking that that's probably a closely guarded secret.

jwatte
06-15-2015, 10:54 AM
Those are custom built servos, right? Must be.

"Actuators." Real robot engineers use the term "actuators."


acquired its strange name because it was built with the same modular actuators used in the Biorobotics Lab’s snake robot project


Key in achieving such a balance is the series-elastic actuators used in the joints to allow what the lab describes as “simultaneous position-velocity-torque control, enabling compliant motions


6038

tigakub
06-15-2015, 12:49 PM
"Actuators." Real robot engineers use the term "actuators."

Yes, of course. :wink:





6038

Hello, sexy.

It does say "simultaneous position-velocity-torque" control which the Dynamixel's also have. I read somewhere that the "motors" have "springs" in them — thus the "elastic" nomenclature. So I guess that bounciness is not simulated by the serv ... er ... actuators, but purposely engineered in elasticity, kind of like biological tendons.

jwatte
06-15-2015, 05:15 PM
I'd assume so too, and that's part of the "series elastic" chain they're talking about.
That also ... changes ... backlash. If your joint is spring loaded, you can have zero backlash with zero load, and then increasing backlash with increasing load. But you have to pay an extra movement cost when working against the spring.
In a walking robot, gravity works as its own anti-backlash loading, so a spring that perfectly counter-balances gravity would make the servo work less hard, but ironically would increase backlash...

tician
06-15-2015, 05:37 PM
Series elastic means there is an elastic element like a spring or rubber rod connecting the drive system of the actuator to the actual output of the actuator, not that it is spring-loaded with a spring connecting the actuator output to the actuator housing to provide a bias. Variable stiffness actuators like those used in the DLR hand (motor driving cable capstan with a second motor driving an arm/bearing to adjust tension in cable) are a form of series elastic actuator and intended to make the actuator compliant and rugged (https://www.youtube.com/watch?v=2JT9rD5VGvQ).

Romain
06-16-2015, 11:20 AM
Hi!

Congratulations for your work on that hexapod!
I like the way it behaves in the video.


I remember reading in another thread about someone trying to use the Dynamixel's load measurement capability, but for the life of me I can't find it again.


Yes I plan to use the ground feedback to create a gait to walk on uneven terrain.
I did not have the time to test the use of the compliance of the Dynamixel to get an image of that ground force feedback.
As I read in that document (p. 10):
https://cyber.felk.cvut.cz/research/theses/papers/480.pdf
I thought I could use the error between the goal position and the present position to evaluate the reaction force of the ground, with a great compliance margin on the femur.
But when the leg is moving, the error is obviously high.
So I thought I may use the LOAD register with a threshold but as tician mentioned, it is dependent of several factors.

Anyway, I will also try to do that sensing by adding FSR sensors at the tip of each leg.

Actually, I am also facing some low rates on the Dynamixel bus. I tried some tricks today (reduce the number of read registers, reduce the time to read the response from the Dynamixel) but I am stuck at 27 Hz :(
(I use the USB2Dynamixel and the ROS Dynamixel stack (http://wiki.ros.org/dynamixel_motor) so my setup is quite different than yours)

Romain

jwatte
06-16-2015, 02:32 PM
not that it is spring-loaded with a spring connecting the actuator output to the actuator housing to provide a bias

True; much better characterization than mine.

It's still the case that series elastic changes how you think about backlash, because there is no "fixed" target position anymore. You also can't necessarily use just actuator sensors to figure out where your target is. If you put the position sensors after the spring, then your control loop will suddenly have to take the spring into account, which becomes a lot more chaotic.

Maybe a good series elastic actuator has two sensors; one for output shaft position and one for post-spring position?

tician
06-16-2015, 03:03 PM
Maybe a good series elastic actuator has two sensors; one for output shaft position and one for post-spring position?
Which is exactly what the 'low cost arm' and metal spiral torque sensor designs achieve by using two sensors (stepper motor with quadrature encoder for drive plus an absolute position encoder in joint after elastic element) or a single sensor (analog opto-interrupter with variable occlusion by 'sloped flag') to characterize the elastic properties of the actuator during operation. The DLR hand achieves this with opposed dyneema cables (one cable/capstan+servomotor for each direction of rotation in the joint) and tensioning arms with position sensors to control and measure the tension in the cables. The DLR arm also requires occasional output position recalibration as the dyneema cables stretch and/or need replacement.

tigakub
06-16-2015, 11:12 PM
Congratulations for your work on that hexapod!
I like the way it behaves in the video.

Hi Romain. Thanks!


I thought I could use the error between the goal position and the present position to evaluate the reaction force of the ground, with a great compliance margin on the femur.
But when the leg is moving, the error is obviously high.
So I thought I may use the LOAD register with a threshold but as tician mentioned, it is dependent of several factors.

Interesting. I didn't think of comparing present position with goal position. I see what you're saying about the error when the servo is in motion. Even with present load, motion introduces a lot of noise. I'm thinking that I could scale down the sensitivity when I know the limb is supposed to be swinging, and only scale it back up during foot-falls.


Actually, I am also facing some low rates on the Dynamixel bus. I tried some tricks today (reduce the number of read registers, reduce the time to read the response from the Dynamixel) but I am stuck at 27 Hz :(
(I use the USB2Dynamixel and the ROS Dynamixel stack (http://wiki.ros.org/dynamixel_motor) so my setup is quite different than yours

Ouch. Well, I think it was tician who pointed out that my slow data rate probably has more to do with how much floating point math I'm forcing the ATMega to do. But 27 Hz is decent, isn't it? Film is 24 fps.

tician
06-17-2015, 06:39 AM
The big issue with using a USB2Dynamixel to read data from servos is that there is no way to aggregate the data on a device prior to waiting for USB packets to get sent to the PC. Basically, the dynamixel packet sent from the servo to the PC will not actually get sent over to the PC in a USB packet until enough data has been received by the FT232RL from the dxl bus or the data/packet timeout is reached (that delay has to happen each and every time you send a dxl packet to/from the PC). The USB2AX and CM-730/Arbotix-Pro get around this a bit by using a microcontroller that can perform the multiple dxl reads at 1Mbps and then combine the results into a single USB packet to the PC.

TXBDan
06-17-2015, 08:26 AM
Nice work on the compliance! Thanks for the inspiration, I want to leave work and race home right now to start working on something similar. I bought some FSRs for feet and started working on integrated contact switches to the MKII hex feet, but that fell to the back burner.

I wonder if with a high enough servo update rate and appropriate load filter tuning it could be stable while walking.

Romain
06-18-2015, 02:00 AM
Basically, the dynamixel packet sent from the servo to the PC will not actually get sent over to the PC in a USB packet until enough data has been received by the FT232RL from the dxl bus or the data/packet timeout is reached (that delay has to happen each and every time you send a dxl packet to/from the PC). The USB2AX and CM-730/Arbotix-Pro get around this a bit by using a microcontroller that can perform the multiple dxl reads at 1Mbps and then combine the results into a single USB packet to the PC.


Oh I was not aware of that timeout before sending the data. This timeout is managed by the host computer, right? Because I looked quickly at the FT232RL datasheet and did not see any value for that timeout.
About the USB2AX, we must use the SYNC_READ instruction in order to agregate the packet I guess. With a simple READ, there is the same timeout issue, isn't it?

tician
06-18-2015, 04:57 PM
If I'm remembering correctly, USB is host centered so all interactions are initiated by the USB host. Not sure about the frequency at which the drivers poll the FT232RL for data going to the PC, but think it might be related to the timeout value used for sending out data. Also hoping that the FT232RL is able to tell the PC that there is more waiting in its buffer to be sent to the PC when it sends a full packet, so the PC will poll it again immediately instead of waiting for the timeout (not sure exactly how it all works). When sending data to the FT232RL, sending a single byte would place it in the driver buffer which will then wait for the buffer to fill or reach the timeout (usually defaults to ~16ms on windows) before actually sending the packet to the FT232RL.

So I'm thinking the entire 'READ' process would be: 1) push N bytes of dxl packet into driver buffer, 2) wait for timeout if not causing 'buffer full' event, 3) send USB packet to FT232RL, 4) FT232RL extracts dxl packet from USB and sends dxl packet on buss, 5) FT232RL receives response dxl packet into its buffer and waits to be polled by PC, 6) PC driver eventually polls the FT232RL and the FT232RL finally sends the dxl response in a USB packet.

tigakub
06-19-2015, 02:29 AM
If I'm remembering correctly, USB is host centered so all interactions are initiated by the USB host. Not sure about the frequency at which the drivers poll the FT232RL for data going to the PC, but think it might be related to the timeout value used for sending out data. Also hoping that the FT232RL is able to tell the PC that there is more waiting in its buffer to be sent to the PC when it sends a full packet, so the PC will poll it again immediately instead of waiting for the timeout (not sure exactly how it all works). When sending data to the FT232RL, sending a single byte would place it in the driver buffer which will then wait for the buffer to fill or reach the timeout (usually defaults to ~16ms on windows) before actually sending the packet to the FT232RL.

So I'm thinking the entire 'READ' process would be: 1) push N bytes of dxl packet into driver buffer, 2) wait for timeout if not causing 'buffer full' event, 3) send USB packet to FT232RL, 4) FT232RL extracts dxl packet from USB and sends dxl packet on buss, 5) FT232RL receives response dxl packet into its buffer and waits to be polled by PC, 6) PC driver eventually polls the FT232RL and the FT232RL finally sends the dxl response in a USB packet.

I might be mistaken, but the data aggregation you're talking about is called Nagle's algorithm, and is a way of reducing seek/read/write latency on block devices, as well as packet overhead in TCP/IP data transmission. In UNIX, you can explicitly enable, or disable, this feature on any file descriptor, including USB devices, which the kernel sees as simply just another data stream. There might still be data aggregation, but turning off Nagle's algorithm should induce the driver to signal the availability of data as soon as any is available. I'm not sure if it's the same with Windows drivers in general, but I remember that WinSock had something similar.

tigakub
06-19-2015, 02:36 AM
Nice work on the compliance! Thanks for the inspiration, I want to leave work and race home right now to start working on something similar. I bought some FSRs for feet and started working on integrated contact switches to the MKII hex feet, but that fell to the back burner.

I wonder if with a high enough servo update rate and appropriate load filter tuning it could be stable while walking.

Hey! thanks! I'd be fascinated to learn of any insights you might have. I've been tossing ideas around in my head, but I haven't had a chance to really try any.

Romain
06-19-2015, 07:45 AM
Hi!

I have plotted the values from the FSR sensor and from the LOAD register of the femur Dynamixel (with compliance_margin set to 0, compliance slope set to 128 and punch to 32) while moving the femur upward and downward, both published at 10 Hz.
So, I post it to give you an idea of the result.

6047

tigakub
06-19-2015, 09:46 AM
Hi!

I have plotted the values from the FSR sensor and from the LOAD register of the femur Dynamixel (with compliance_margin set to 0, compliance slope set to 128 and punch to 32) while moving the femur upward and downward, both published at 10 Hz.
So, I post it to give you an idea of the result.

6047

Woah! That's great! There is an obvious correlation, but the FSR produces much cleaner data. What FSR are you using, and how is it mounted? Does your bot have 4dof limbs?

TXBDan
06-19-2015, 09:53 AM
Interesting. The FSR is acting more like an on/off switch. Can it's circuit be tuned to provide more intermediate fidelity? From that data i think the dynamixal data (once filtered) would be more useful as it conveys more information during step transitions which would necessary for smooth foot response.

My ideas for now are to give each foot a "planted" binary state and have the gait generator assign them accordingly. This won't cover the intermediate loads during step transition, but it is sensorless and may work a little bit. The average servo load while walking is then just the average of the "planted" feet.

As a second step, i think i could use a load threshold level to determine which feet are on the ground and thus include those in the load average.

Once, a foot is considered in contact with something (via load sensor threshold), i think i'll use a proportional controller, possible a PD, to adjust the foot position relative to the error between current foot's load and the average load. This is basically simplifying our system down to a force-spring system. That way the foot should respond well to various forces; fast, slow, large, small, etc. This is where you need good transient information from the load sensor in order for the foot to follow tightly.

Could you post the raw load sensor data as a CSV or something? I'd like to play with filtering it.

TXBDan
06-19-2015, 05:15 PM
Also, what lead you to your compliance and punch tunings?

Compliance margin = 0. (default 1) I assume you wanted as tight of control as possible? Is there any oscillation or vibration present?
Compliance slope = 128. (default 32) This is most flexible (least rigid) option. Does this allow for better load data? Maybe a steep slope creates a more binary torque drive?
Punch = 32. This is default so i see you left it alone.

Thanks again!

jwatte
06-20-2015, 11:15 AM
Compliance margin = 0. (default 1) I assume you wanted as tight of control as possible? Is there any oscillation or vibration present?

My experience with a Phantom X II: Hanging in air, you'd absolutely get oscillation with that setting.
On the ground with constant loading, it may do better.


Compliance slope = 128. (default 32) This is most flexible

This probably helps in avoiding the oscillation, as long as there is some load to act as dampening.

Romain
06-22-2015, 02:57 AM
Hi!

First, I am sorry, I was away this WE so I could not have access to my computer.



There is an obvious correlation, but the FSR produces much cleaner data. What FSR are you using, and how is it mounted? Does your bot have 4dof limbs?


I am using the small FSR 400 (7,62 mm diameter) because I have those. They are mounted on a new foot that I've printed in 3D. There is a slot between the foot and the leg where I put the sensor. The slot is held open by four springs which are compressed when the leg touches the ground.

But I am not sure of the design yet and I cannot use the 3D printer anymore these days (the Makerbot extruder is too fragile...). So I will put the sensor above the feet with some tape for my experiments.

My hex is a standard PhantomX MkII so 3 DOF per leg.



Interesting. The FSR is acting more like an on/off switch. Can it's circuit be tuned to provide more intermediate fidelity?


The values from the FSR almost use the full scale so I cannot reduce it. The ADC is 12-bits so I am not sure I can get a better fidelity.



Could you post the raw load sensor data as a CSV or something? I'd like to play with filtering it.


Sadly, I did not record the values but only take the screenshot. So I redo the experiment, but I moved the FSR sensor a little bit by the time so the absolute values changed.

I did try a rolling mean and rolling median. But at 10 Hz, I cannot use a large sliding window.

Here are the 4 outputs, with a window of 6 values.
6055

And a rolling median with only 4 values, it is not so bad.
6056

The CSV:
https://gist.github.com/154c309a0d855ec9134f




Also, what lead you to your compliance and punch tunings?


For the compliance sttings, I have taken the ones from that paper (p. 11), I did not try another.
https://cyber.felk.cvut.cz/research/theses/papers/480.pdf

TXBDan
06-22-2015, 08:21 AM
^awesome, thanks for that and for running the test again to collect data. I'll see what I can come up with tonight for a filter. That raw data doesn't look too bad though. I'm thinking of a discrete time "RC" filter, ie y[I] = y[i-1] + alpha * (x[i] - y[i-1]). You can tune the LP cutoff with alpha: https://en.wikipedia.org/wiki/Low-pass_filter#Discrete-time_realization these filters don't introduce any (much) phase lag and provide a little more control.

The linked paper, holy crap this is the perfect summary of everything I'm trying to do. I sort of feel guilty though, like I just cheated and was given the answers. hah. I'm hoping I can use his compliance theory, and improve it with my sinusoidal foot trajectories and maybe even use a more complicated gait since we have the luxury of the sync-read. He's limited to reading only two servos per cycle with the traditional read.

Thanks! I'm back to being obsessed with this.