Build a Robotics Portfolio for MSc and PhD Applications

You do not need access to a humanoid robot to demonstrate useful robotics skills. A small project with clear assumptions, reproducible code and an honest evaluation can show how you approach research.

A portfolio mapped to what labs inspect

Robotics labs read portfolios the way engineers review code: they clone the repository, run the README, and judge you on what happens. That sets the standard — every flagship project needs a question it answers, a reproducible artifact, and a visible failure analysis. The strongest portfolios for MSc-to-PhD progression contain three to four projects of decreasing polish and increasing curiosity: one simulation project with a trained policy and an ablation, one hardware project — even a modest manipulator or quadruped deployment — with documented debugging, one course project extended beyond its assignment, and one open-source contribution with a merge history.breadth signals interest; depth in one project signals readiness.

The connective layer is documentation. A two-minute video per hardware project beats a page of prose; a requirements file and a one-command run script beat a 'contact me for details'; a commit history beats a single mega-commit. And the honesty layer matters disproportionately in robotics, where simulations break and hardware fails: portfolios that show a failed trial, the diagnosis and the fix read as research maturity — exactly the behaviour a supervisor is hiring for.

A twelve-week portfolio build

Portfolios are built, not found, and twelve weeks of focused work produces a credible one. Weeks 1-3: pick the flagship question and reproduce one published baseline in simulation — the reproduction itself becomes project one with an honest write-up of what broke. Weeks 4-7: extend beyond the baseline with one change you can ablate (an observation, a reward term, a controller layer); document the training curves. Weeks 8-10: the hardware layer — borrow the lab's desktop arm, the university club's quadruped, or a low-cost rig; even one deployed policy with video transforms the portfolio's texture. Weeks 11-12: packaging — READMEs with results tables, one-command setup, demo videos, a five-minute portfolio page linking everything, and a commit history cleaned of secrets but not of history.

The final pass is the reviewer simulation: hand the portfolio to a fellow student with a stopwatch and ask them to find the answer to 'what can this person do?' in three minutes. Whatever they open first is your real flagship; whatever they skip is decoration. Reorder by their behaviour, not your pride, and the portfolio you submit will match the portfolio that gets read.

Choose one question per project

Pick a task that you can test and explain: track a walking trajectory in simulation, estimate a robot's pose from sensors, plan an arm movement around an obstacle, or compare two approaches to balance control. State the problem, your assumptions, the method and the result. Show at least one failure case. If your solution only works under ideal conditions, say so.

You can use a simpler robot to study a component of a humanoid problem. Arm control can teach manipulation; a legged model can teach contact and balance; sensor fusion can teach state estimation. The connection should be precise. Do not call an arm simulation a complete humanoid system.

Make the evidence easy to inspect

For each project, include a short description, a diagram or video if it clarifies the result, code where you can share it, and instructions to reproduce the experiment. Report what you measured: tracking error, successful grasps, recovery from a push or another metric that actually fits your task. Explain the baseline you compared against and why the comparison is fair.

Keep your contribution distinct from a tutorial or starter repository. If you adapted an existing controller, say what you changed. If you worked in a team, identify your part. A supervisor should be able to tell what you understand, not just what the finished demo looks like.

Connect it to the lab

Stanford's advanced manipulation course links robot arm control to whole-body humanoid control. That illustrates a useful way to present a portfolio: show how a focused technical exercise connects to a larger research problem. For each application, choose the one or two projects most relevant to that lab's current work and explain the link in a few sentences.

A portfolio cannot replace the formal requirements of a programme. Check the university's application page for the documents it actually requests, then use the portfolio to support the claims in your CV, statement or supervisor email.

Show the failure cases too

A portfolio entry is more useful when it shows a baseline, your change and the resulting behaviour. For a simulated grasping project, include the environment settings, installation instructions and the conditions under which the method fails. A short video can help, but it should connect to code or a technical explanation. Label simulated results clearly. Do not describe a simulation demo as hardware experience. End the entry with the question you would investigate next, which can provide a natural bridge from an engineering project to a research application.

Make one project reproducible enough to inspect

A useful portfolio lets a reader understand the question, see the result and inspect how it was produced. Start with one substantial project rather than many unexplained videos. Put a short description at the top: the task, your contribution, the main method and the limitation the viewer should keep in mind.

If the project is simulated, say so beside the result. State which environment and robot model you used, what you changed and what remained from an existing implementation. Give appropriate credit and follow the code or dataset licence. Running another person's demonstration can be a learning step, but the portfolio should identify your own investigation.

A project evidence pack

Keep the quick overview separate from the technical detail, so a supervisor can assess relevance without searching through a large repository. Use understandable filenames and test the links from a logged-out view if you intend the material to be public. Do not expose private employer data, credentials or material you do not have permission to share.

Report results with their conditions

A demonstration video does not establish a success rate. If you report performance, explain the task, number of runs, initial conditions and how a success was defined. If you only tested one run, state that rather than presenting it as robust performance. Show a failure case when it reveals a meaningful limitation or design decision.

For a control project, useful evidence might include tracking error and response to a defined disturbance. For perception, explain the dataset split and how the output affects the task. For a mechanical project, show the design decision, analysis and measured behaviour where available. Choose evidence appropriate to the question instead of adding every metric you know.

Connect the project to an application

Select the part of the portfolio relevant to the target programme. A short note can explain how the project prepared you for a method or question in the advertised work. Keep proposed future extensions separate from completed results. If hardware validation is planned, label it planned until it has happened.

Should my portfolio contain only humanoid projects?

No universal rule applies. Relevant work in controls, estimation, manipulation, mechanics or simulation can demonstrate preparation. Explain the connection instead of renaming unrelated work as humanoid research.

Is a polished website necessary?

Clarity matters more than presentation complexity. A well-organised repository and concise project page can be sufficient if the evidence and instructions are easy to inspect.

Keep the evidence available

Test the instructions in a clean environment where practical and record any hardware or licence dependency. A clear explanation of a dependency is better than a run command that silently assumes access to your personal setup. Keep large or restricted datasets out of a public repository unless sharing is permitted.

Questions applicants often ask

What should a robotics portfolio contain for PhD applications?

Three to four projects with one deep, reproducible flagship: a trained policy with ablations, or a hardware deployment with video. Add open-source contributions and honest failure analysis. Reviewers clone repos — README, environment file and one-command setup are the portfolio.

Is simulation-only experience enough?

It can carry an application when the simulation work is deep — ablations, reproducible training, honest baselines — but hardware evidence, even on modest platforms, is the differentiator. If no hardware is available, document the sim-to-real gap analysis itself; labs read that as preparation for the real problem.

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
• How to Write a Focused Humanoid Robotics PhD Proposal
• Compare PhD Salaries and Stipends: Net Income, Fees and Living Costs