Mechanical & system design
Designing a humanoid-class system is not “more servos” — it is load paths, vibration, thermal headroom, wiring serviceability, and failure modes. This module frames how mechanical choices lock hands with software and operations.
Learning outcomes
- Trade off stiffness, mass, and thermal paths for one subsystem.
- Explain why service access changes total cost of ownership.
- Link mechanical choices to integration risk in a pilot.
Loads, materials, power/thermal, human factors for service.
Red-team a CAD or photo: list three service nightmares.
One-page design review memo; post summary on the Forum.
Self-check
Arms vs legs — what differs?
What is “integration debt”?
STEM alignment: engineering design process, constraints & trade studies, communication of design intent.
Why this chapter matters
This is where “the robot works on paper” turns into “the robot can actually be built, serviced, and operated without constant surprises.”
Carry forward from earlier pages
Bring in assumptions from Software, Communication, and the platform chapters so your CAD, wiring, and access decisions match the stack you really intend to run.
Design lenses
- Stiffness vs mass: arms need repeatable contact; legs need impact tolerance — often opposing goals.
- Power & cooling: sustained walking + manipulation draws real watts; budget thermals early.
- Service loops: can a field tech replace a joint in < 30 minutes? If not, downtime dominates.
- Integration points: align CAD, electrical pinout, and software frame IDs — one naming scheme end-to-end.
- Humanoids specifically: coordinate G1/H1-class constraints with morphology tradeoffs.
Best next move: continue into industry if you want to translate integration tradeoffs into pilot constraints, or revisit the humanoid chapters if you are still deciding what form factor makes sense.