Got to a max speed of 1.2 Hz and climbed well. There were some issues of slipping on each step.

We did some system ID experiments to see if we could figure out why a derivative term would make sense on force control. As Mark pointed out, a D-term is essentially jerk. The results of the sys ID experiment aren't very clear. Basically they show that we can follow a signal up to about 10 Hz with uniform gain. After that the magnitude starts to ramp up. We stopped after running a sinusoid through at 30 Hz. So, if the Magnitude is constant up to 10 Hz, I'm not sure why we a) need a derivative term, and b) the gains should be lower at higher speeds.

Mark's suggestion - the difference is in the attachment phase at high speeds. Will try to lower gains in attachment phase and increase them back during stance.

4/17/07 - Part B

After looking at the data below, one might ask, why don't you just lower the gains, they still look like they are too high. I did that, lowering the proportional gain to 0.5. I get better results at high speeds, but worse results at low speeds, indicating that the proportional gain is a function of speed. Lower speeds = higher gain. Higher speeds = lower gain. In fact with the P-gain at 0.5 I got it to climb at 1.0 Hz. I tried to climb faster, but for some reason whenever I started the gait, the speed would drop to 1.0 Hz exactly.

Note by Clark: Matt, the speed dropping to 1.0 Hz is simply a gait thing. GaitRunner? will (badly) assume that gaits should max out at 1 Hz. This was as a safety measure so that we never accidentally set the robot going faster than the motors could handle, and most of our gaits have never pushed up against that limit. The one exception is the carpet gait. To get around the 1 Hz limit, add something like: float max_clock_vel = 1.5; to the RC file of your gaits (gaits/mygaitname.rc). In this example, that'll set the limit at 1.5 Hz rather than 1 Hz.
-- ClarkHaynes? - 18 Apr 2007

4/17/07 - Part A

Added a derivative term to the normal force control. Got max speed up to 0.8 Hz. Failed at 0.9 Hz. First plot is at 0.2Hz. Compare it to the last plot on this page and notice the reduced overshoot

Now at 7 Hz. Compare to the plot below. Still very bad, but qualitatively it climbed better.

4/16/07 - Part C

Lowered the normal force gain once more to 1.5. Got RiSE to Climb at 0.7Hz. Failed at 0.8 Hz. The normal force data looks strange though. First of all there is massive overshoot during attachment. The forces are climbing to between 11 and 14 N. Then when all four feet are on the ground the normal forces are varying by +/- 5N around the desired 4 N value.

Also check out this new video:

• treeclimbingday2.mov:

4/16/07 - Part B

Got RiSE to climb the eucalyptus tree at 0.5 Hz. It was jerky, but it did it. It climbed at 0.4 Hz relatively smoothly. The trick was reducing the normal force proportional gain to 2, which prevented the feet from bouncing off of the surface.

4/16/07 - Part A

Some data of normal force while climbing. Looks like the gains are a bit high. Lots of overshoot. When I climbed at higher speeds (above ~0.25 Hz) with the motor assist device this was even more evident. The legs would chatter on the ground. Normal force P Gain set to 4.0.

Reduced the P-gain to 2 N. The climbing qualitatively looked good. Can't really say if it was that much smoother. Speed was 0.2 Hz.

4/13/07

Got good results climbing trees. Max speed of 0.26 Hz on eucalyptus tree. video shows 0.2 Hz. Should climb better on oak and redwood with different dactyls - longer for eucalyptus and longer and curved for oak.

Got better results from a number of things:

• added dactyls to tail to increase friction and prevent sliding in the vertical direction
• moved the rear feet from the "rear" to the "middle" position to compensate for the increased friction in the tail. Otherwise it would pitch back too much when the front feet were off the tree.
• modified the gait to include a "pause" so that the robot is not climbing unless all four feet are on the tree. This allowed more of the motor torque to be used for squeezing.
• modified the squeezing torque. 8N when two feet are on the tree. 4N when all four feet are on the tree.
• added a crank offset to pull the robot into the tree when the opposing feet are in flight. This prevented pitch back of the robot.
• changed the leg springs to the stiffest available spring. This also prevented pitch back
• tree_climbing.mov: Quicktime H.264 Movie 360x240

-- MattSpenko? - started 13 Apr 2007