Andrew and I will be working on dry adhesive feet for QuadraRiSE, to see if we can get it to climb glass. Major anticipated problem is compliance, due to the large size of the feet (2 to 3 times that of StickyBot) - it is harder to achieve a percentage of surface area contact that is sufficient to support QuadraRiSE. Will need to have different "sensitive zones" on the underside so the foot can conform to the climbing surface. Otherwise we will have to make the leg motion align rigid feet perfectly with the surface as it touches down.
Sheer size of feet may be an issue. We are trying to scale down, as really big feet might interfere with leg movement, compliance, and will increase the potential for unanticipated problems. Further tests will be done to find an optimal foot layout that will hopefully minimize this problem.
Flexibility of ankle joint will probably have to be tweaked, to account for the rotation of the RiSE feet in the plane parallel to the surface, so as to avoid torque that may "twist" the feet off the surface.
Foot needs to be designed to accomodate attachment/detachment motion of RiSE legs.
Recently explored idea of "pressure compliance" i.e. using an empty space - either a fluid sac or the inside of a loop cross-section - to apply equal pressure to all parts of the foot. Fluid sac may not be feasible due to manufacturing difficulty, and possible failures or punctures. Cross-section loop may work, but implementation will need close attention to design and lots of tuning. (Preliminary prototypes were made but the photos did not turn out so well.) Open loop had problems with adhesion %. Fluid sac remains untested.
I am leaning towards a simpler and hopefully more reliable approach: using a flat or slightly concave foot that is flexible, and using the large mass of RiSE to press it against the wall. Perhaps using a frame that transfers normal force from near the ankle to closer to the toes, driving them against the wall. This is kind of what SpinyBot is doing, but with a continuous contact surface as opposed to two points.
I haven't actually heard any reasons why a big, rigid foot would not work on QuadraRiSE. Unfortunately, it is difficult to test on the robot, leaving us with less sophisticated, throw-together methods, though this might not be a big issue given that we are only in the preliminary stages of design.
We are trying to control the flexing of the foot using the forces applied by the wall to the feet - i.e. either the normal force or the upwards reaction force that holds the robot up. Both show some promise.
Normal force, using spring compression system - the feet are mounted on a suspension system, which when compressed, will release tension in a cable leading to the feet, causing them to flex outwards (towards the wall).
Strengths: potentially simple design, straightforward and easy to engineer. Easy to implement with multiple toes.
Weaknesses: Depends heavily on spring tension and precise tuning. May have irregular or unpredictable performance.
Tangental force/tangental - normal combunation, using lever mechanism - ankles are mounted onto a simple lever system (possibly with a wheel to control cables). Tangental + normal forces applied to lever system cause wheel to rotate forward, releasing tension in cable and pressing feet against wall.
Strengths: less springy and more durable mechanism than above.
Weaknesses: Design more complex: not sure if everything will work perfectly.
People seem generally receptive (or not noticeably adverse to) the two-directional actuation mechanism. Doing force calculations to figure out how to minimize the foot's buckling tendency.
Conclusive results will be posted over the weekend.
Will friction in the cable joints affect the mechanism's performance? This might be a matter of concern - two loops per foot section equals 12 to 16 loops total! This means that for the down-curling motion, unless we have perfectly smooth cable-passes, and that the cable stiffness is negligible, the toe sections that are closer to the ankle will have a tendency to move before the sections that are further away. The prototype is exhibiting symptoms of this.
Forever trying to simplify the design and minimize problems/unpredictable behaviors.