Rapid Unscheduled Disassembly
We are not talking about rockets, but apparently, I had to face a Rapid Unscheduled Disassembly of the Mast Tower's head. It doesn’t take a degree in aerospace engineering to know that, ideally, rockets aren’t supposed to blow up. Similarly, a robot is not supposed to break apart during a test. However, this is exactly what happened. During the test, a coding error made one leg go rogue, turning the robot into a bit of a daredevil and resulting in a not-so-graceful tumble from the table. Luckily, the legs and other moving parts survived the crash, but poor Continuity's neck got the worst of it. The elevation mechanism to control the pitch angle of the Imager (the head of the Remote Sensing Mast), is a simple 3D-printed extension of an aluminium servo motor horn. This helps reduce the mechanical complexity, but also makes it much more fragile when the robot has to survive a fall.
Lesson learned: While we love keeping things light and simple, we've got to find that sweet spot between lightweight design and toughness. I am patching up Continuity, adding some extra code safety features, and making sure the robot is ready to handle whatever comes its way. Here's to smoother tests in the future!
Weight Optimization and Two feets roll balancing
Watch: Two feets roll balancing
In a recent overhaul, Continuity's design underwent a meticulous weight reduction, shedding non-essential components for enhanced efficiency. Then, I started testing balancing on the roll axis, a crucial step towards achieving stability. However, friction-induced squeaking in the plastic joints posed an initial challenge, partially limiting the movements of the legs and causing very annoying noises. I managed to fix the problem using WD-40 lubricant. Balancing is achieved using a simple accelerometer, with future plans to integrate force pressure sensors on Continuity's feet for enhanced feedback. The code I'm using for balancing is not very well refined and occasional failures are acknowledged. But generally speaking, it works well!
Walk Cycle Refinement
After ensuring a strong enough structure and sufficient current to power the motors, efforts were dedicated to refining the walk cycle of a single leg. Until this point, legs moved along predefined coordinates defined manually, making the movements quite clucky. I decided to avoid inverse kinematics calculations to reduce processing time and resources: this should leave more available memory to the RPi4 for Computer Vision tasks. So, I preferred using forward kinematics, finding a relation between the angles and end effector of the legs. I decided to make the end effector move along a precisely defined curve. This curve comprises two interconnected segments: the upper curve (a), similar (but not) a parabola, and its counterpart below (b), completing a seamless loop.
One of the standout features of this approach lies in its adaptability. The parameters of the functions governing the two curves can be fine-tuned, allowing for the creation of diverse step shapes. Whether it's a stable, measured gait or a more dynamic stride, adjusting these parameters provides versatile options. Furthermore, the execution speed of each step is a customizable element, adding another layer of control to the robot's locomotion.
Walk cycle testing and pushups
Watch: Walk cycle testing and pushups
Between the 6th and the 16th of November, I worked on the control of the legs. The first step was to ensure motors were actually powerful enough to lift the entire body of the rover. Motor strength, however, is not the only parameter affecting this test's success or failure: the length of the leg joints also plays an important role. If the femur or tibia is longer than the other, it can affect the torque required at the joint. Generally, a longer lever arm decreases the torque at the end of the joint. Therefore, if the femur is longer, it may require more torque to move the leg than in a situation where the femur and tibia are more balanced. A combination of the design I was initially using, plus a bottleneck caused by thin cables that were limiting the current draw, was not allowing the robot to lift itself. I use four motors that run between 5 -7 Volts and 1 - 2 Amps powered by a 20000 mAh power bank with an output current of 3 Amps. Nominally, this should not be enough to power four motors. However, good management of the current draw obtained through software allows motors to run anyway. Some suggestions for testing such a configuration are using suitable wires (possibly not jumper wires for connecting the motors to the battery), trying several iterations to find the best leg joint design, recording videos, and taking photos and notes about what you are doing. This helps keep track of your progress, as well as what is not working.
Single Leg Prototype - Test 3 (Walk cycle, ground contact interaction)
Watch: Single Leg Prototype - Test 3 (Walk cycle, ground contact interaction)
Over the summer I worked on a simple walk cycle, ensuring the smoothness and precision of the movements. I installed an accelerometer that allows me to simulate a change in ground inclination: the algorithm changes the leg walking cycle, adapting it to the simulated terrain slope. The limit switch discussed in the previous post works simultaneously, raising the leg when an obstacle is encountered. This behaviour would not make sense in a real-world environment, but it is a good starting point for future more complex leg-ground contact interactions.
Walking instead of driving
Background: Nowadays, we are quite used to seeing walking robots. Both companies and independent engineers tried to build their own at various levels of complexity. Some of the most well-known are Boston Dynamics’ Spot, MIT’s Cheetah, Unitree Robotics’ Laikago, ANYbotics’ ANYmal, etc. They are all designed for on-Earth applications. Instead, the list of existing walking robots for Space exploration is limited to ETH’s SpaceBok, JPL’s LEMUR, FZI’s Lauron V, and a few others. Most of these robots are hexapods or other ways inspired by arthropods' shapes. Interestingly, before choosing wheeled rovers as a valid option for exploring Mars, it looks like NASA was interested in walking robots as well. In 1989, under a contract with NASA's Jet Propulsion Laboratory, Martin Marietta developed several alternative rover concepts for unmanned exploration of the planet Mars. One of those concepts, the 'Walking Beam', is the subject of this paper, also referred to as Martin Marietta beam walker rover. Unfortunately, only a few pieces of information are available about it online. According to the design, the walking rover used two platforms that alternately translate one with respect to the other, to propel it. There were seven legs, all of which actuate in the vertical direction only. The legs were grouped into two sets: a quadruped inner base supporting the lower payload assembly, and a tripod outer base supporting the beam assembly. In addition to the seven legs, there was a translation system for locomotion and a rotation system for steering. In total, there were nine actuators, one for each of the degrees of freedom.
Comment: Despite the clear absence of flexibility and natural dynamics, the Martin Marietta beam walker rover shows some interesting features. The body is suspended from the ground thanks to some legs that alternate their position keeping the robot in a mechanically stable position at each movement. A set of cameras (and presumably of sensors) is located on a tower much higher than the robot body. I found these images on an old JPL archive about the Pathfinder mission, together with a collection of pictures of the Sojourner rover. From this, I can deduce that NASA is (or at least, was) interested in walking robots for exploring Mars. What happened then? Maybe they realised wheels are much more manageable and ideal in terms of power consumption (a critical aspect of planetary exploration). So, there must be a great reason for using legs instead of wheels, a reason good enough to close an eye on its low efficiency in terms of energy.