Links

Page about Sal's alternative control: RiSEVoltStateControl

Page about tree climbing with current robot: TreeClimbingProgress

Page about body analysis for tree climbing: TreeRobotDesign

Current Status

Experiments testing the power in RiSE's motors (March 26, 2007)

Tests I ran (the following is from Clark's email):

Test	Crank Direction	RiSE orientation
#1	Positive	On belly
#2	Negative	On belly
#3	Positive	On back
#4	Negative	On back

Plot showing results of all test cases! During "Forward" tests the "Pure Crank (F)" gait was run, and during the "Reverse" tests the "Pure Crank (R)" gait was run. With 200g weight hung from each leg. Robot was actually flipped upside down onto its back during the "Back" tests.

Note by Clark: It should be noted that when on its back, the available range of motion of the wing DOF is small, thus the smaller movement by the drooping motor. So that explains one difference between tests #1 & #2 and #3 & #4. Can we attribute the "preference" (a.k.a. when the motor moving in reverse is between -pi/3 and -pi) for failure angle in #3 and #4 to mechanics? Why are tests #1 and #2 seeming to fail relatively anywhere in [-pi,pi]? (I might suggest redoing #3 and #4 with RiSE on its side, and the wing angles at 0 degrees, hanging weights from the legs closer to the ground). It should also be noted that the motor that stalls in each case is the one needed to stall in order for the wing angle to droop.
-- ClarkHaynes? - 29 Mar 2007

One other note: There are faint blue and faint green lines on this plot (assuming you used motorlines.m), perfectly on the target line slopes. This means two things: (1) my bug fix for logging motor target positions worked, and (2), the motor targets are totally correct, in terms of position.
-- ClarkHaynes? - 29 Mar 2007

• I tried making RiSE do pull-ups by just its front legs. It pulled itself up about halfway through the crank change in Stance but then stopped. Clock speed was 0.051.

• I repeated Clark's experiments with hanging weights on the legs, and did some others. I made a movie of what I did and it's posted here:

RiSE_Weights_Testing_small.avi -- Small (11Mb) movie showing testing

RiSE_Weights_Testing2.avi -- Full-size movie (58 Mb) showing testing

In summary:

• If the clock is stopped the legs can support 500g with only drooping about 1cm.

• If the legs are moving with clock speeds ranging from 0.005 to 0.122, the legs start drooping with 200g added to them, but they return to their original trajectory after drooping about 60 degrees. With 400g added to the legs they cannot lift themselves back up to the original height anymore. After we had been hanging weights on one of the legs for a while, it started drooping with only 100g.

• If the legs are moving and you pull on the legs in the crank direction with a spring scale when the crank is in the Stance position, they stall at around 8-10N. This seems to be independent of how much weight you put on the legs in the normal direction! Tests were done with 0-300g hanging off the legs, and in all cases the cranks were able to pull 8-10N. Note that our robot weighs about 2.9 kg, so indeed it should not be able to do a pull-up if each leg can only pull 10N at most!

Also, the legs were executing the following trajectory when doing these experiments:

• Stance, Detachment, Flight, Attachment were set in the ClockMap to each take 0.25 percent of the time.
• In the LegTrajectory, all of them were set to have no wing change and -0.25 crank change.

So, there are some speed discontinuities between when the leg is in the different sections of the gait. It seems to be slowest in Stance and Flight and fastest in Attachment and Detachment.

The following plot shows motor angles and speeds when 100 and 200g weights were hung off legs. I believe there was no load on the legs from times 0-10 or 15 seconds, 100g on the leg from ~15-45 seconds, and then 200g on the leg from ~50-65 seconds. From ~65 seconds to the end it had 100g on it again. As you can see, motor 4 stops at various crank angles.

The following plot shows wing angles and torques for 300 and 400g weights. In the movie, this was when I was seeing the maximum weight the legs could hold and still return to their original trajectory occasionally. If you recall, with 300g on the leg it would droop and then recover but with 400g it could not lift itself up and the leg dragged the weights around on the table. This shows the motor angles and speeds, wing angles, and motor torques during that experiment. The leg had 300g hanging off of it from about 10-44 seconds, and 400g from 44-66 seconds (when the wing doesn't return to the "up" position ever).

Experiments determining total force generated by robot (Feb. 1, 2007)

desired vs actual hip and crank angle for the stanford tree gait

• crankangle.png:
  

• hipangle.png:
  

The quad tree code:

• Quadtree.avi:

Stanford tree gait with normal force control code:

• stanfordtree.avi:

We made the robot try to climb the eucalyptus tree with dactyls. It was not able to pull itself up the tree, but cycled its legs around (i.e., the person belaying the robot was still holding lots of the robot's weight). The normal force was controlled at 3N/leg squeezing in on the tree trunk, which it did reasonably well (there was lots of jitter but the average value was indeed 3N). Also, due to this squeezing action during which force was controlled but position wasn't, the robot body rolled back and forth an awful lot.

Following are plots of the total forces for the entire robot:

• Run1: Total forces for entire robot:
  

• Run2: Total forces for entire robot, minus a weird lateral force measurement:
  

I thought it would be illuminating to just plot the normal+traction forces, because it seemed like the lateral forces were higher than they should be (see plot below). Also, when the legs are in the middle of their stride, the Lateral force is perpendicular to the direction of the crank's motion so should have no bearing on the amount of force produced by the robot. But, I guess while we were running the robot, the legs were 90 degrees out of phase so it would affect the force output for at least two of the legs.

• Run1: Just the normal and traction forces:
  

• Run2: normal + traction:
  

• Run1: Just the lateral forces, they look larger than they should for leg 0, at least..:
  

• Run1: For comparison, just normal forces for all legs. This also allows you to see the steps the robot took, and how when it is not moving the forces are accurately controlled to 3N/leg:
  

Week of August 21, 2006

8/22/06

Sangbae toes - shingles, max speed= 0.195. I don't really know why there is such a speed increase. We repaired/adjusted the spines on the toes before we left, but I can't believe that is the only reason. Also the shignles could be different, but they look the same to me.

I just remembered that I changed the tail angle as well. There used to be 4 or 5 washers in the tail. Now there are three. This reduced the wing offset from 14 to 9.

Week of July 24, 2006

7/27/06

Re-ran the tests on shingles with sangbae's toes at 90deg. We saw some definite improvement, but it fell after 17 successful steps. The data shows what is starting to appear to be a "typical" failure. All four legs appear to be well engaged. One leg moves off the wall (more often the rear leg, but that could just be a coincidence at this point) and the other leg on that side begins to slip. We see several "micro" slips occur before it becomes too much and the other side of the robot fails. See also the "Plots with commentary showing what happens when the robot fails" below for more information about failures.

Also, we realized that it is important to calibrate the Force sensors with the robot oriented vertically (in the climbing position), because the feet have some mass and there will be offset errors if the robot is calibrated in any other orientation.

7/26/06

We ran the robot on three outside surfaces yesterday. The results were not that promising. You can see a video of our performance here: QR062507experiments1.avi: divx (Note that I realize that it says my name in the title. This was obviously a mistake and an artifact of the default state in imovie!).

We are also looking at some of the force data. On a first pass it seems as if although a foot may be "in stance" there are times when it is not supporting any load. When another foot then comes off the ground, the robot fails since only two feet are supporting the robot. Perhaps we inadvertently disabled the pawing function? Or perhaps we need to just ensure that a foot does not detach until we are sure that the other feet are carrying a load.

Here is another video that shows some upclose shots of the feet. Note that we have two different types of feet on the robot. The front left foot uses Sangbae's design. The other three use Alan's design. It appears as if the size of Sangbae's toes is not appropriate for the surfaces that we are climbing. However, the there is good engagement. Perhaps a redisgn with larges spines would be appropriate.

• QR062507expclose2.mov: Uses quicktime, I believe you need quicktime 7 to run it.

Some interesting plots of force space from data taken on the larger rock surface seen in the movies:

compare this to the data from the library endurance run:

A couple interesting points.

• The frictional-adhesion model is applicable to spines, to a point. The spine/surface contact is based on friction, and so the harder you pull down the more friction force you can sustain. There is a limit to how hard you can pull based on the asperity or spine breaking/bending. Also there is some angle at which you pull away from the wall where suddenly the normal force is not sufficient for the friction force you are depending on, and the spines will slip off the wall. This angle will vary within the foot depending on the individual spine/surface contacts. However, there are also dynamic effects to the frictional adhesion model with spines: if the spines are moving too quickly (sliding friction) they will not be able to gain purchase on asperities. Furthermore, since the spines have mass they have a tendency to bounce off the surface if they are moving quickly. So you have to slow the foot down a little when attaching it to the wall (at least, you can't be moving super-fast).

• Leg 2 was the leg that failed in this test (Front left), although this is not evident from these plots. Perhaps the spines are just too small for this surface? However, results from other tests indicate that the front left leg can hold more load than the other designs. This could be a result of the hard stop that is on the larger toe designs, but is absent from the smaller spines.

• There is non-neglible friction in the flight/attachment stage. This could be a good method of tuning the gait, since a gait change should be able to eliminate this. - Note this appears not to be a problem if we cut out the first four steps of the robot after it is placed on the wall.

• Similarly, the detach gait could be modified to have a smoother, zero-normal force detachment.

• The front right leg is spending too much time in positibe normal force and both rear legs have too much adhesive force.

Plots with commentary showing what happens when the robot fails

These plots are in pairs, one showing the forces and wing/crank angles vs. time, and the other showing the forces on a F_traction-F_normal plot. The F_t-F_n plot has the points labeled with numbers which correspond to times on the force-vs-time plot so you can correlate the data. The force-vs-time plots are annotated so you can see the progression of events that led to the robot falling.

The first pair of graphs shows a phenomenon we observed several times while climbing a stucco surface that should be really easy to climb, since the stucco grains were quite large (3mm). Essentially, one of the feet came off the wall for unknown reasons. Then, the other foot on the same side of the robot was scheduled to Disengage and take another step, and it did so even though the other foot on the same side was not carrying any weight. This caused the robot to fall since now neither foot on that side was carrying any weight. The code should be changed so that the robot doesn't take a step if it sees that the attached feet on the same side are not carrying any weight, and instead it should try re-attach those feet.

GreenBldgStucco_060725_152945_SecondSlip_forceplot.png:

GreenBldgStucco_060725_152945_SecondSlip_FnFtplot.png:

The next several plots were done on a pebbly wall with a lot of fairly jagged 1-2cm rocks embedded in concrete. These plots show that sometimes, one foot is in flight and the other foot just suddenly fails for no apparent reason. Perhaps sometimes the foot/wall contacts are failing because the leg in flight jostles the robot... sometimes the legs go through flight quite quickly.

PebblyWall_060726_140306_FirstSlip_forceplot.png:

PebblyWall_060726_140306_FirstSlip_FnFtplot.png:

PebblyWall_060726_140306_SecondSlip_forceplot.png:

PebblyWall_060726_140306_SecondSlip_FnFtplot.png:

Week of July 17, 2006

7/20/06 After taking a closer look at our climbing performance, we noticed that the wall was at approximately 80 deg. We re-ran the tests at 79deg and at 90 degrees. We were able to successfully climb the 79 deg, but we failed at 90. We also had a slew of failed runs. Its amazing how much difference slight changes in the feet make to the climbing performance. After a few failed runs, we adjusted the pitch of the toes forward a couple of degrees and we saw immediate improvement. We also tried some new toes out (actually old toes on the new ankle - see SummerUpdates) and found it to be a superior foot for the asphalt shingles. It is doubtful that it would be able to climb the "library" surface well because of the size of the spines, but who knows.

• QuadraRiSE06-20-07divx.avi:Climbing 79 deg
• QR-Fail90degdivx.avi: Failing at 90deg

7/19/06 We adjusted the ankle compliance. It is now at 1 in the front 3 in the back 0 on the sides. This made a very big difference. In addition we changed the code so that if a foot is in dettachment or flight, the other feet stop. We relize this is conservative, but if guarantees that three feet remain on the ground at all times. With these two changes, we were able to climb the asphalt shingles. We got to about 8 strides and then started slipping a little bit. Some more tweaks might result in more improvements, but I'm not sure what tweaks are next. I can conclude that a quadraped RiSE CAN climb a wall, but of course it is not as robust as a hexapod.

7/17/06 I updated the force balancing code to employ the changes made to ForceBalBehavior? over the past few months. No noticable change in performance. It occured to me that the major problem is still two feet coming off at the same time. I then ran a simple open-loop gait. Got better performance, but it still couldn't take more than 10 steps or so before failing. Need to adjust ForceBalQuad? .cc to not allow more than one foot to come off at the same time. Best to confer with Clark first before hacking away.

7/10/06 I made a test wall out of asphalt shingles. QuadraRiSE CAN support its own weight on it, and can take a few steps. The performance is about the same as what we saw with the small toes on the cinder blocks at Fort Polk. The main problem now is the fact that two feet will still come off the ground at the same time. This just can't happen with a quadraped. I can look at the code to see if I can modify it so that it doesn't happen, however, I think that would require a more detailed approach that just a quick code change.

6/7/06 Clark had a look at the graph and he said that it seemed to be reasonable, so that's good. I ran QuadraRiSE with dactyls on some ceiling board and this other soft opencell rubber type material we have in the lab, and this time I ran it near vertical. Nothing really impressive, but there are two key things that are missing that can be altered to make what I think would be big differences:

1) The robot needs better purchase on the surface. This could either come from carpet, or better yet, from the spinytoes. BDI should have the ankles done this week. Hopefully they work well so we can get our hands on them. I think that if we get spinyfeet on quadrarise, we will see much better performance.

2) Mistakes in the timing of the feet are much more evident in the quadraped. Examples include pretty much any combination of two feet coming off at the same time. We saw examples of this at SWRI, but it didn't really cause too many problems (Although we can't forget that near failure at the top of our last run on brick). Some modifications to the behavior to prevent this from happening need to be done.

I also want to reiterate that this is done at near 90deg and that at the lower angles we have some issues with the legs sagging because they are in too much of a sprawled position. This could be taken care of by decreasing the wing angle, but some modifications of the foot roll angle would also have to occur.

5/18/06

Here is a plot of the phase offset for a run. There is some debate on our end as to whether or not it looks reasonable.

• quad_bal_phase_offset.jpg:
  

5/17/06 It's ALIVE! After fixing some bugs and some new code by Alan, it appears as if the robot is using the force balancing algorithm properly. It doesn't climb all that well though. We tried it at ~60deg and it didn't climb. The main issue is that we are using Sangbae's toes which work well on things like sheetrock, but not so well on stucco. So why don't we use the sheetrock? Well, that might be the next test.

For now I lowered the angle down to 44deg and am going to adjust the gait so that the wing increases more allowing the foot to come off a bit more. Because we only have one leg suppporting the side of the robot, it tends to sag more when the other leg on the same side lifts off.

The mm_update_period problem still exits

5/8/06 Mechanically quadrarise is fine. The body is comprised of leg module, sheet metal extender, delrin extender, sheet metal extender, leg module, and tail. The carrier board is mounted on top of the rear leg module. Two RMCs are connected to the carrier board. The wireless ethernet hub is temporarily placed on the tail.

Code wise, I've narrowed down the problems some more.

• In the current configuration, with mm_update_period set at 3000, only two of the four LSANs can be connected without the startup routine failing. It is not a function of the LSAN wiring as it does not matter which two LSANs are connected.
• If we connect the third RMC then we can connect all 4 (or 6 if we wanted) LSANs and the supervisor will start up properly. However, if all 3 RMCs are connected, we cannot switch out of calibration mode. If only two RMCs are connected then the code recognized this and will allow us to switch modes.

So we are in a sort of catch 22. With all three RMCs connected we can properly start up, but can't switch into a gait mode. With two RMCs we can switch into a gait mode, but can't properly start up with all the LSANs connected. The temporary solution is therefore to change the mm_update_period to 4000. This will solve the startup problem, but of course something else is going on here.