How to Write a Focused Humanoid Robotics PhD Proposal

A useful humanoid robotics proposal starts with one research question you can test. Define the task, connect it to the lab's work and explain what your evaluation would show.

A proposal sized to the field's real gaps

Humanoid proposals win funding when they target a named deployment blocker. The IFR's 2026 assessment names the field's gaps directly: safety, reliability, lack of training data and an unproven business case — four sentences that double as a research agenda. A strong proposal therefore states one blocker as its problem (for example, contact-rich manipulation under uncertainty), one bounded scope (upper-body bimanual tasks, no dynamic locomotion), one evaluation with a real metric (success rate on a fixed task suite, ablated against a learned baseline), and a hardware-or-simulation claim that matches the host lab's actual equipment. Panels reject both overreach ('solving general-purpose robotics') and vagueness ('exploring learning-based control').

Structure follows the standard European budget — problem 20, literature 25, methods 30, plan 15, contribution 10 per cent of words — but humanoids add two sections worth stealing space for: an evaluation protocol with baselines and a compute/hardware statement. Labs read the compute line closely, because a proposal promising whole-body reinforcement learning on hardware the lab does not own is a red flag about preparation. Name the rig you will use; name the simulator if hardware is shared; state the fallback if both are queued.

The worked mini-example

Watch the structure work on one compressed example. Problem: 'contact-rich bimanual manipulation fails under object-pose uncertainty'. Boundary: upper-body tasks on a fixed-base dual-arm rig; no dynamic locomotion; two object classes. Literature: three lines — model-based grasping under uncertainty, learned manipulation policies, and the sim-to-real gap as their interface. Methods: work package one trains a policy in simulation with domain randomisation over pose noise; work package two transfers to hardware with a tactile-feedback correction layer; evaluation on a ten-task suite against the lab's published baseline. Plan: months 1-6 pipeline and baseline replication, 7-18 policy development, 19-30 hardware transfer, 31-36 write-up with the thesis chapter map. Contribution: a transfer protocol and an open task suite.

Count the sentences a panel can check: a named rig, a named baseline, a task count, a success-rate target, a month-by-month plan. Five checkable claims, each in the host lab's gift to verify — that density is what 'feasible' means in practice, and it is exactly what the same structure produces for any humanoid topic you shrink to thesis size.

Define the problem and its boundary

Suppose you are interested in a robot carrying an object while walking. The broad challenge includes grasping, perception, balance, route planning and hardware. A narrower research question might ask how a controller handles changes in the object's mass during walking. State what you will hold constant, what you will vary and why this question matters to the work of the target lab.

Read the lab's publications and identify the methods and limitations the authors actually report. Do not claim that nobody has solved the problem unless your literature review supports that claim. A proposal can be valuable even when it improves a known method under a clearly defined condition.

Describe an evaluation you could carry out

Outline a baseline method, a proposed change and measurable outcomes. For the carrying example, you might compare balance or task completion across several payloads and disturbances in simulation. If hardware access is available, explain what a limited physical test would add. Also say what a negative result would mean. This makes the proposal a research plan rather than a prediction of success.

Work in humanoid robotics often spans locomotion, manipulation and perception. The Robotic Systems Lab's research overview gives examples of those connected areas. Use a lab's own work to motivate your question, while keeping your proposed contribution separate from research the lab has already completed.

Show why you can start

Close the proposal by connecting your preparation to its first steps. Mention relevant control, mechanics, perception or programming work that you can substantiate. Name the methods you still need to learn and how you would begin. If a call specifies a project or proposal format, follow that call first: some advertised PhD projects ask applicants to respond to an existing research brief rather than submit a wholly new topic.

A concise proposal answers four questions: what will you investigate, what does prior work say, how will you test your approach, and why is this lab an appropriate place to do it?

A small experiment is easier to defend

Suppose you want to study a humanoid recovering from a push. Define the terrain, the disturbance and the information available to the controller. Compare your proposed method with a named baseline under the same conditions. Success could mean fewer falls or lower tracking error, but you would need to choose and justify the metric. Include a simulation-first stage and explain what a hardware experiment would add. If robot access is uncertain, describe what can still be learned in simulation and which conclusions would remain untested.

Turn the broad aim into one testable question

Start by naming the task, the conditions and the outcome you would measure. A humanoid carrying an object while walking involves locomotion, manipulation, perception and contact. A single doctorate does not need to address every part at once. You could propose studying one controller's response to payload variation while holding the robot, terrain and sensing arrangement fixed.

That is a proposed study, not a claim that the problem is new. Before calling it a gap, review relevant papers and identify what they actually tested. Separate limitations reported by the authors from limitations you infer. Cite the original work and explain why the proposed conditions would add useful evidence.

A hypothetical evaluation plan

Treat the entries as design choices to justify, not a ready-made novelty claim. If you change several components at once, explain how you would identify which change affected the outcome. Use ablations where they answer a real question rather than including them as a checklist term.

Plan the simulation-to-hardware boundary honestly

Simulation can support controlled comparisons and repeatable experiments, but its contact, actuation and sensing models are assumptions. State which assumptions matter to your question. Document time steps, limits, noise and any parameter variation used to test sensitivity. A successful simulation is evidence about that simulated setting; it should not be described as demonstrated hardware robustness.

If hardware is available, propose a limited validation with the lab's approval and appropriate operational procedures. Explain what the physical experiment adds and which conclusions would remain simulation-based. If access is unconfirmed, keep it as a conditional extension rather than the foundation of the entire plan.

Make a negative result interpretable

A useful proposal explains what you would learn if the new method does not outperform the baseline. Perhaps the chosen representation does not help under the tested uncertainty, or the extra computation is not justified by the improvement. Define the comparison well enough that either outcome can be analysed without changing the success criteria after seeing the results.

Should I promise a new humanoid platform?

Only when platform development is an explicit, resourced part of the project. Otherwise, base the plan on confirmed equipment or a simulation platform and identify the contribution you can complete with it.

How much detail should the proposal contain?

Follow the programme's limit. Prioritise the question, evidence, methods and feasibility over a long survey of every humanoid research direction.

Specify the baseline implementation

Record which implementation and version would provide the baseline, the conditions in which it is evaluated and any changes needed to run it on your model. Otherwise, an apparent improvement may reflect a different setup rather than the proposed method.

Questions applicants often ask

What should a humanoid robotics PhD proposal contain?

One named deployment blocker as the problem (safety, reliability, training data), a bounded scope, a methods section with an evaluation protocol — fixed task suite, baselines, success-rate targets — plus a compute and hardware statement matching the host lab's actual equipment.

How specific should the evaluation plan be?

Specific enough to be falsifiable: '80 per cent success on a ten-task manipulation suite, ablated against the learned baseline' beats 'improved performance'. Panels read measurable targets as feasibility evidence — the single strongest predictor in robotics proposal review.

Official sources and further reading

Requirements and policies should be checked for your programme and application date.

• ETH Zurich RSL: legged locomotion research
• MuJoCo: simulator overview
• RSS: Expressive Whole-Body Control for Humanoid Robots

Related guides

• Choosing a Humanoid Robotics PhD Topic: Match the Problem to Your Skills
• Build a Robotics Portfolio for MSc and PhD Applications
• Compare PhD Salaries and Stipends: Net Income, Fees and Living Costs