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
You really are approaching the design as if it’s intended to be a commercial project…
2 Likes
I try and approach most of my projects that way.
I do like to document everything and have references to fall back on.
As the project has moved forward i am updating a Technical Support User Manual for it to keep everything in one place.
Might be overkill but fills those gaps between waiting for parts to arrive.
2 Likes
Our first full specimen has arrived at the Facehugger Lab.
Initial inspections and first fix will commence soon but delighted with the progress.
2 Likes
Again, thank you for seeing what i am trying to portray in my work.
I am greatful that my project has come across that way and your comment is inspiration to keep going.
2 Likes
Um… have you seen the level of professionalism, creativity (and realism) of your work? If someone designed (for example) a Ferrari but nobody gave any praise… it’s still a Ferarri.
2 Likes
Thats a very nice analogy.
A very philosophical way of putting it.
Please put that on a T-Shirt. 
And thank you.
2 Likes
Below is a video for a side project to this.
A separate board ill be designing but will be used alongside it to help log its distance.
Ill probably open a separate thread for this, but will see how it goes first.
Video below.
1 Like
UPDATE 
While i wait for some parts to arrive for the above post i thought i would share some information on a simple device i have built for the project.
Our simple data logger helps the operator to understand some simple parameters and issues the robotic Facehugger may have.
Like a little Hugger Black Box.
Below are some of those parameters and how it works:
Session Counter Initialization:
•The readLastSessionCounter function reads the last session number from the SD card and sets the sessionCounter to one more than the last session number.
Reading Last Session Counter:
•This function reads the HuggerLog.txt file line by line to find the highest session number recorded. It assumes that the session numbers are in the format Session X - Total Distance (m): Y.
Start Logging on Startup:
•Logging starts as soon as the device is powered on, as indicated by loggingActive being set to true.
-Start Time:
The sessionStartTime variable records the start time of the session when logging starts.
-End Time:
The sessionEndTime variable records the end time of the session when logging stops.
-Duration Calculation:
The session duration is calculated by subtracting sessionStartTime from sessionEndTime.
-Log Maximum Speed:
Track and log the maximum speed reached during each session.
Logging Data:
•The logData function appends the session number and the total distance to the HuggerLog.txt file.
Threshold Filtering:
•The code now ignores accelerations below accelMinThreshold and above accelMaxThreshold.
These thresholds help to filter out small noise and large unexpected movements such as picking up the device.
This approach will help mitigate the effects of both small vibrations/noises and large movements that are not representative of the robot’s normal operation, ensuring that the logged data is more accurate.
This data will then be shared directly on Facehuggerlab.com
2 Likes
I’m stunned by the professionalism of any of your work, Facehugger included.
Not much to say other than that and I feel like it’s too little for the amount of data you posted… Oo
What’s missing for the project ? (parts)
2 Likes
Thanks Eric.
There was a small redesign on the MCP joint.
I was using off the shelf universal joints hiwever they become limited at certain angles and so i required a new idea. I came up with a joint design i am calling a Direct Driven Orbital Axis Joint.
It allows for me to create a wider angle of attack as well as support more stability on the joint.
It will also make the whole finger more manageable in terms of maintenance and calibration.
Ill post more info of this soon.
I am currently away for an EBME Expo.
2 Likes
innerbreed DDOAJ …!!
1 Like
I have to join everyone else and compliment the level of professionalism you have approached this with. Very impressed!
1 Like
Welcome to the forum and thank you for visiting my thread and the kind comment.
I hope to share more soon.
1 Like