After three months of testing Continuity's front legs only, I'm excited to share that the walking rover has taken a giant leap forward. I've just rolled out an update, bringing the two rear legs into action. This development is a game-changer because now I can dive into real 4-legs-balancing tests, exploring pitch and roll axes movements, along with trying out various walking gaits and manoeuvres. As of now, Continuity is equipped with 8x 25 Kg Servo Motors, each thirsting for 5-7 volts and drawing 1-2 Amps. The entire body is currently made out of 3D-printed PLA, but I've got big plans for the next version: several structural parts of the body will be converted into a sleek carbon fiber structure. The mobility system, aka the legs, is also in for an upgrade, transitioning to a robust aluminium CNC machining.
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.
After a week of testing, the mast tower v.1 was ready! I tested two versions of the head (with a slight variation in weight - the final version is the white one) and verified the precision of the 3D-printed gearbox: despite a backlash of < 0.5 cm, it performs smoothly and is visually precise. This is something that must be improved in v.2, possibly reducing the backlash to < 0.2 cm or lower. I also compared the mast tower of Continuity with Mimas' one: the difference is really impressive, but despite being shorter, Continuity's mast tower is much more capable! It will be equipped with a higher resolution camera (compared to Mimas' camera), laser distance sensors and other instruments!
The mast tower is a crucial element of Continuity: it is a tower-shaped component that elevates key camera systems and sensors, giving the rover a human-scale perspective on its environment. Because I decided to use only servo motors, where possible, I had to find a way to increase the rotation range of the motor. The servos I'm using are 25 Kg full-metal motors with a rotation range of 180°, meaning that they cannot be used directly for the azimuth rotation (along the z-axis). I decided to 3D print a 1:2 (2x) multiplier gearbox. You can see it in the LHS photo below. The design is probably not the best because the gears are very thick and not space-saving. I still decided to give them a chance, so I designed a holder for a bearing and an enclosure to keep everything tight and reduce vibrations. Now, when I rotate the servo by 180°, I get a 360° rotation. There is still an evident issue: 3D-printed gears are not 100% accurate, and backlash is not something I can ignore.
Until the day of this post writing, the front and rear upper linkages of the leg were connected to the motors using aluminium flanges. Generally speaking, this component is great but performs poorly if an overhung stress is applied to the motor shaft, causing vibrations that tend to increase after intense testing of the leg. To (hopefully) fix the problem, I changed the design, substituting the flange with an aluminium bracket that can be secured to the motor shaft using small set screws. Additionally, this design increases the contact area between metal and plastic, improving the force distribution.
This configuration has been tested by running the same tests performed with the previous design. Results show that not only the vibrations are reduced (as well as the chance that screws get unscrewed due to vibrations), but also improve the stability of the leg when it was tested sideways and upside down.
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.
Watch: Single Leg Prototype - Test 2 (Smooth control, ground contact reaction)
As discussed in the previous post, smoothness is something I want to work on: it helps reduce vibrations that a clunky mechanical movement would otherwise cause. In addition, it is more visually appealing.
I used the pigpio library, and I controlled the motors smoothly using a function that I called servo_smooth(motor, angle, speed)
. The distance between the current servo angle and the target angle is subdivided into small steps that act as a time delay: by changing this value, it is possible to control the movement speed. Additionally, using the function servo_sync(motor1, angle1, speed1, motor2, angle2, speed2)
in multithreading, two threads run the servos (one each), allowing me to set a certain angle and the speed I want the motor to run, moving synchronously and smoothly. Finally, I implemented a simple ground contact check by snap-fitting a limit switch in the lower plastic linkage. The program I was running in the video lifts the leg as much as possible, reacting when a force is applied to the foot. This is just an "ON/OFF" configuration, which is quite not the best solution for sensing the ground correctly.
Watch: Single Leg Prototype - Test 1 (Synchronous movement)
I 3D printed and tested the first leg prototype: the structure is relatively strong, despite the thin thickness of the plastic joints. I used PVC tubes for the links high torque full-metal servo motors to power the leg. The control is achieved using basing sequential coding in forward kinematics.
I used the library pigpio to move the motors, without caring about the movement smoothness. Instead, I tried to define some points the leg had to reach to achieve a step cycle.
From the pigpio library, using pi.set_servo_pulsewidth(pin, angle)
, it is possible to control the servos easily. N.B.: The motors react immediately to the GPIO trigger, meaning that multiple commands can be sequenced, obtaining a parallel/simultaneous movement of the servos. However, this does not allow us to change their speed. This can be achieved by adding a delay between each leg position, even if the result is a bit clunky and definitely not smooth.
Background: The designs of already-existing quadruped robots are all quite similar, either similar to Boston Dynamics' Spot, MIT's Cheetah, Unitree Robotics' Laikago or Go1, or to the ANYbotics' ANYmal. The first group share a crucial aspect of the leg design: all leg motors are located in the shoulder joint, reducing the force that would be otherwise required if motors were located one in the shoulder and one in the elbow joint. In this design, the elbow is controlled using an extension linkage. ANYmal (and other similar designs), however, have one motor in the shoulder and one in the elbow, clearly visible due to a bulky round box on each leg of the robot. The only quadruped robot I could find that does not conform to these two design types is ETH's SpaceBok. Additionally, this is the only quadruped robot specifically designed for space exploration. Its leg design is fascinating since it is based on four parallel linkages controlled by two motors located on the shoulder joint. It strongly relies on energy conservation to jump using the back drive of brushless motors, simulating a spring.
Comment: By observing all of these designs, it is clear they cannot be considered "rovers": the majority of the robot body is occupied by the motors and the battery, and there's very little space available for cargo. Indeed, they can carry much weight, but it has to be stored on top of the robot, increasing the overall height of the centre of mass. Cameras are either located in front of the robot or on each side of its body, making them not ideal for observing the surroundings: they are suitable for finding obstacles but utterly useless for collecting imaging data of the surroundings. Expensive and custom motors are used to control the legs; brushless motors are usually relatively weak and require using a gearbox. This means increasing the overall robot weight and space occupied by the actuators inside the robot body.
I proposed a completely different approach that merges the valid aspects of existing designs with the peculiar characteristics of NASA/JPL's Mars Rovers. A mast tower is located on the top-front part of the body, raising the primary camera at a higher point, allowing it to rotate on the vertical axis (azimuth) and pitch rotation (elevation). Apart from other technical design choices discussed in the spacecraft section of this blog, it is visible that much space is available on the rover body: cargo is an essential part of Continuity and can be stored on the robot's upper deck or the side module located on the side of the mast tower. I decided to use high-torque full-metal servo motors instead of brushless motors because they guarantee an extremely high torque (about 25 Kg on the 1st cm of radius from the shaft) relative to their small scale and have incredibly high precision. Interestingly, Martin Marietta walking rover was designed with some of these elements, too: the mast tower and an upper deck are also present in that design!