Looking pretty nice, good job with the design. but that servo structure … I’ve never seen it before, did you custom made those for your legs ?
Info on the servo parts can be found at my NEW website…
innerbreed.co.uk
in “buy my products”
Sorry iv not put a direct link, my phone is playing up.
Thanks.
So… 11+ years on.
7 design iterations.
And the design has finally landed on its feet. (Fingers in this case).
Id like to take some time (because 11+ years is clearly not long enough) and gather together a portfolio of all the previous designs that’s now led me to the 7th Generation Robotic Facehugger System that will be presented soon.
I will show each design in detail and how each design generation has improved on the last.
Keep an eye out.
2 Likes
Really looking forward to it! Any plans to work on a “skin”?
1 Like
2 Likes
My project started a few years ago. All the way back in 2013. Well initially I touch on doing this project in 2010 but nothing actually came to light until 2013 when I first started designing it.
So that’s a good place to start this, I think.
The project shared here today is a walking robot conceptualised and replicated from the alien film franchise creature known as the Facehugger.
Gen 1 was designed in 2013.
Although previous to this I was exploring robotics and animatronics, so I had somewhat of an understanding of how I was going to pull this project off.
Generation one was my first conceptualised design.
Designed to run off a Botboard and SSC-32 and HS645MG servos
It was a cable driven design with external placed actuators that ran into the body from a main control box along with the power supply. Although the design was never finished, I was able to learn a lot from this and any mistakes or problems that I ran into, I was able to rectify in later models.
The design was simple and didn’t really push any boundaries and I didn’t really run into any issues, it was just that the approach was wrong and that made me cease moving the project further.
Gen 2 was designed in 2016 - 2017
The ideas behind this was to use smaller integrated dc motors with integrated feedback systems in each joint.
I was basically building my own servo joints with this one.
With the 90 degree motor to joint arrangement I was able to get really nice thin fingers with this design. I had opted for a 4 degree of freedom leg design to allow more natural movements when transitioning through its gait cycle. I didn’t find the legs to be very strong and so the idea to complete this was abandoned.
Again, with this one I did choose to power it externally due to weight and space inside of the robot.
Designed to run off a Arduino Uno and SSC32 and N20 custom motors
Gen 3 was designed in 2020 - 2021
Quite possibly the nicest looking design. With that said also the most complex one yet with everything compacted into the small body. Motors, power, control boards etc.
I had designed my own integrated motor systems with feedback at each joint.
The design also incorporated peristaltic drives in the sacks for added effect.
Generation 3 was more of a hexapod with only 6 walking fingers as the two front fingers were used as “feelers” and wasn’t designed to support any of the walking motion.
Due to the complexities in manufacturing with material shrinkage a lot of the tolerances were out and of course this created issues with gear meshing and cable routing was very intricate.
Designed to run off a Arduino Mega and SSC-32U and custom motors
Gen 4 was designed in 2021 - 2022.
Generation 4 joins the cable driven group and ironed out most of the issues in Gen 3 but still following the custom-made integrated actuator idea.
A material change helped out with tolerances but did mean the design was almost too heavy to actually walk. With the design slightly larger than want I intended; I soon abandoned it.
Designed to run off a Arduino Mega and SSC-32U and modified RDS3115MG Servos
Gen 5 was designed in 2022 - 2023.
A brief design was done for Generation 5. Only to explore using stock motors and custom feedback. The body was again oversized, but I did start to shrink down the electronics setup. Its over size was quite expensive to manufacture and ultimately, I abandoned this idea.
Designed to run off a Arduino Nano and SSC-32U and modified RDS3115MG Servos
Gen 6 was designed in 2023.
Generation 6 was a direct driven mech. Designed to be stronger and incorporated linear actuators.
Actuator throw and speed was always going to be an issue that I knew about when I started and I did hope that I would find a solution for this later down the line.
This was the most expensive build out of all its predecessors.
Designed to run off an Arduino Mega and PQ12-R Linear Servos.
Gen 7 was designed in 2024…
its true to say that there has been a number of things that are the reason for such a long term project to have taken this long, as well as reasons why there has been so many design ideas.
Family and work life etc is an obvious one but also as technology has moved forward, so did the designs. Not only in terms of design packages, and what they would offer the project but also the physical parts available on the market. Control boards have got smaller with bigger features. Servos have got smaller with higher torque… all these things.
Coding is also a factor and massive improvements have been made since day one.
My skill in all these areas has also been a massive factor. Learning new things and implementing them into the projects.
Well… So Generation 7!
More to follow…
3 Likes
Oh wow… just… wow
2 Likes
Thanks man.
Should have a delivery soon of some parts but i am holding out on ordering the motors due to cost so that will delay things a bit.
However it has allowed me to concentrate on other aspects of the project.
I have all the legs assembled but dont really want to mount them until i have the servos and pulley cables installed.
2 Likes
This is incredible timing for the new Aliens: Romulus movie which seems to have quite a few facehugger scenes in the trailer.
2 Likes
Yeah i kind of wished i was further along with this and had something to show as the new trailer release would have ran parallel with the project. Hoping by the actual cinematic release ill have this up and running (no pun intended).
Might even get a chance to attend an opening. 
.
1 Like
A small update:
So i am just waiting on some new custom servo hubs for the pulley cables as the groove wasnt quite as wide as id of liked. They should arrive in a week.
I have ordered half the servos for now so i can at least test one side of the legs (fingers) before i order the rest just to make sure it will actually work. 
Here is a shot of the body with the pulley channels (v-gooved bearings set up.
I will start adding in some of the electronic components and once the new hubs arrive i can then complete half the assembly so really looking forward to that.
3 Likes
Those project are so expensive… I can understand that…
1 Like
This is my Electronics Tree if anyone is interested in seeing my setup:
Electronics tree.pdf (1.9 MB)
Image and pdf attached.
Also if of interest here is my CodeFlow chart:
CodeFlow.pdf (456.6 KB)
Again image and pdf attached.
The CodeFlow chart is simplified for ease of navigation. Obviously there is a lot more to this but it gives a basic overview of what’s what.
Here is my ACS (Angular Coordinate System) used for programming parameters.
Here is my CCS (Cartesian Coordinate System) used for programming parameters.
I love having everything down on paper so to speak as it helps build the project profile as well as allow me to reference later when required.
Much of this is on my facehuggerlab socials so most have seen these but i hope you enjoy them here.
Again as always… More to follow on next update.
2 Likes
This is perfect. I really enjoy looking at these schematics 
I don’t think there are so many detailed projects here posted.
1 Like
Really handled like a PRO project.
2 Likes
So having been quiet for a while i can reassure that the work hasn’t stopped.
I just took a little rest:
I have a shipment arriving this week (Friday) and i am hoping to share the full assembly shortly after.
In the meantime i wish to share some of the technical information for the project below:
Having explored a few element of generation 7 it became apparent that some major changes needed to happen.
If some of you are following my socials you’ll know that generation 8 is now a thing.
With the new improvements we are now using a direct driven design (no cables) as well as a more optimal electronics layout.
Electronics layout
With the use of control rods it has eliminated at lot of the backlash, complexity and cost.
As i said the final parts all arrive this week and so i really look forward to assembling this. I am really hoping to not have to move into a generation 9, however with that said i am very confident that generation 8 will be awesome.
Please feel free to get your updates other ways and join the main social page:
Admin please remove if not allowed.
2 Likes
Id like to share some of the coded parameters with you.
My code is loosely based on the famous Hexapod Phoenix code but with lots of changes and features that fit the robot i am building.
TRANSMITTER SMOOTHING:
I wanted a more dynamic approach to the control and similarly i also wanted to add a smoothing or rapping motion to the movements:
The following code takes the raw PPM signals sent from the Nano to the Mega and applies a logarithmic/exponential curve to both the start and stop of the input signal which makes the start of each movement look more dynamic and the stop of each signal ramp down, rather than just start and stop.
void RC_Controller_Input()
{
/* Check if there is serial data available*/
while (Serial1.available() > 0) {
// Read the incomingline*/
incomingLine = Serial1.readStringUntil('\n');
/* Use a String Tokenizer to extract values separated by space*/
index = 0;
char *ptr = strtok(const_cast<char *>(incomingLine.c_str()), " ");
while (ptr != NULL && index < 8) {
ppmReadings[ppmIndex][index] = atoi(ptr);
index++;
ptr = strtok(NULL, " ");
}
ppmIndex = (ppmIndex + 1) % NUM_READINGS;
/* print the averaged received data*/
if (ppmIndex == 0) {
Y_INPUT = map(calculateAverage(ppmReadings, 0), 0, 255, 0,255);
X_INPUT = map(calculateAverage(ppmReadings, 1), 0, 255, 0,255);
Z_INPUT = map(calculateAverage(ppmReadings, 2), 0, 255, 0,255);
W_INPUT = map(calculateAverage(ppmReadings, 3), 0, 255, 0,255);
rawJoystickY = Y_INPUT;
rawJoystickX = X_INPUT;
rawJoystickZ = Z_INPUT;
rawJoystickW = W_INPUT;
smoothedJoystickY = smoothingFactor * rawJoystickY + (1 - smoothingFactor) * smoothedJoystickY;
smoothedJoystickX = smoothingFactor * rawJoystickX + (1 - smoothingFactor) * smoothedJoystickX;
smoothedJoystickZ = smoothingFactor * rawJoystickZ + (1 - smoothingFactor) * smoothedJoystickZ;
smoothedJoystickW = smoothingFactor * rawJoystickW + (1 - smoothingFactor) * smoothedJoystickW;
}
TEST GAIT
I created a “TEST” Gait pattern array.
Test gait is designed to make the front two fingers change their stepping turn after each new cycle
has completed. This creates a dynamic gait meaning each new cycle creates a new gait pattern by
having variable movements in the two front fingers. By allowing only the two from fingers to generate random positions with in the gait cycle the gait will remain stable from the “Structured Order” group of fingers.
This approach will create an undetermined, and unique gait that will appear more natural.
It looks like this:
int R; // Storage variable
int L; // Storage variable
int TEST_case[8] = {R, 3, 5, 7, 2, 4, 6, L}; // 8 Frames
// Example:
// LP or RP can randomly fall into any of the positions below.
// Random Placements: ↓ ↓ ↓ ↓ ↓ ↓ ↓
// Structured Order: LR RF LM RM LF RR
In the gait structure it looks to see if the current gait cycle has finished and if it has finished it then randomly picks and assigns a number which represents a position that it fall in for the next cycle of the gait.
if (FRAME < 1) {
// Generate new random values for R and L after each cycle has completed
R = random(1, 8);
L = random(1, 8);
I feel i have significantly improved the gait analysis for this project and i have created some awesome features (still to test) lol
Compute walking Trajectory lengths
It computes the length of the X, Y, and Z trajectories based on user input. The smoothedJoystickX, smoothedJoystickY, and smoothedJoystickZ variables appear to represent joystick “Smoothed” input values, and are scaled to produce trajectory lengths of up to 90 degrees (for X and Y) and 35 degrees (for Z).
It computes sine and cosine values for the Z trajectory, which are used later to rotate the finger.
It sets the GAIT_SPEED variable, which is used to determine the time between frames of the finger’s movement animation.
The value of GAIT_SPEED depends on the gait_speed variable, which presumably represents the user’s choice of walking speed.
Compute walking Finger_Amplitude
This is a function called “Compute_Finger_Amplitude()” that calculates the X, Y, and Z amplitudes for a robotic finger’s motion.
The function takes into account the position of the finger’s knuckle and distal joint and the trajectory of the finger’s movement.
The function first calculates the total distance from the center of the body to the tip of the finger in the X and Y planes by adding the DistalPos_X/Y and Knuckle_X/Y values. It then computes a rotational offset using sin and cos functions based on a rotation angle (rotZ) and the total X and Y distances. The rotational offset adjusts for any rotation of the finger from its original position.
The X and Y amplitudes are calculated by adding the TrajectoryX/Y (which represents the desired movement in the X/Y Plane) and the rotational offset, and then dividing the result by 2. The amplitudes are then constrained to prevent the finger from crashing into other fingers.
The Z amplitude is then calculated based on whether the absolute value of TrajectoryX + rotOffsetX is greater than TrajectoryY + rotOffsetY.
If it is, the Z amplitude is calculated by multiplying the TrajectoryX + rotOffsetX by a step height multiplier and dividing by 4.0.
If it is not, the Z amplitude is calculated by multiplying the TrajectoryY + rotOffsetY by the step height multiplier and dividing by 4.0.
Overall, this function is used to calculate the X, Y, and Z amplitudes for the finger’s motion, taking into account the position of the finger’s joints and the desired trajectory of the finger’s target location.
Front Finger control mode
This mode also can set z step height using capture offsets
The movement of each servo is mapped based on the joystick input, and the movement is constrained to certain limits. The movement of the knuckle MCP (Metacarpophalangeal) joint is controlled by the left/right axis of the joystick, while the movement of the knuckle PIP (Proximal Interphalangeal) joint is controlled by the up/down axis of the joystick.
Finally, the code also adjusts the height of the robotic finger based on the inputs from the joystick,
and locks in the final height adjustment if the “capture_offsets” flag is set to true.
These are my current controller inputs:
===== C O N T R O L S _ R C ===========================================================
X_INPUT Right Stick U/D = Walk Mode - Walk Forward/Back
= Translate Mode - Move body Forward/Back
= Rotate Mode - [Pitch]
= Finger Lift Mode - Raise/Lower Front Right Finger
Y-INPUT Right Stick L/R = Walk Mode - Sway Left/Right
= Translate Mode body Left/Right
= Rotate Mode - [Roll]
= Finger Lift Mode - Yaw Front Right Finger
Z_INPUT Left Stick U/D = Walk Mode - Gait Speed
= Translate Mode - Heave UP/DOWN
= Rotate Mode - Heave UP/DOWN
= Finger Lift Mode - Raise/Lower Front Left Finger.
W_INPUT Left Stick L/R = Walk Mode - Rotate in place [Yaw]
= Translate Mode - n/a
= Rotate Mode - [Yaw]
= Finger Lift Mode - Yaw Front Left Finger
SF_TOGGLESWITCH = Disable System / Restart
SE_SWITCH3WAY = Select: Modes
Gaits
Calibration Mode
= S1_POT (Modes) = Translation Control
= Rotate Control
= Finger Lift Mode
= S1_POT (Gaits) = Walk using Tripod Gait
= Walk using ripple Gait
= Walk using Tarantula Gait
= Walk using Xeno Gait
I will look at publishing the whole code once up and running and i also have some questions about some other features i wish to add.
Excited to share that part.
2 Likes