Robotics Portfolio Projects That Impress and Ones That Don't

A robotics project impresses when it runs unattended, survives something going wrong, and can be watched on video, not when it is ambitious and unfinished. Reviewers spend minutes, not hours, so evidence that a machine worked beats scope on paper every time. That flips if you are aiming at one specific team: build on what that team runs, whether ROS 2 or HORUS, and the match matters more than the depth. The rest of this post is for people early in robotics choosing what to build next, with limited time and probably no robot in the room.

You have a list of project ideas and no way to rank them. One is a robot arm that sorts objects by colour. One is a quadruped, because the videos look extraordinary. One is the thing a friend built last year, which you could finish in a fortnight but which feels like copying homework.

Somewhere in a browser tab there is a course you paid for and abandoned in week three. There is a parts order sitting in a basket you have not placed, because you cannot tell whether the money buys you anything a stranger would care about.

And the advice you get contradicts itself. Build something nobody has built. No, build something familiar so people can tell at a glance that it works. Do it in simulation, it costs nothing. No, employers only respect hardware. Use the framework everyone uses. No, that produces the same project as everyone else's.

What you actually want to know is narrow: of the things you could plausibly finish, which ones make a stranger stop scrolling, and which ones make them close the tab? That question has a clearer answer than the noise around it suggests.

Does the project you choose actually change whether anyone is impressed?

The project you choose matters far less than whether you finish it and can show it moving, which is why most project-selection advice aims at the wrong target. Reviewers behave alike whether they are hiring managers, lab supervisors, or the maintainer of a repository you want to join. Each opens the page, hunts for something proving a machine did the thing, and gives it a couple of minutes. Inside that window, ambition is invisible and completion is obvious. A modest wheeled robot that stops before it hits a chair leg, filmed from a cold start, beats a half-built humanoid torso with three months of commits and no footage. That is not because anyone prefers small work. It is because the unfinished torso supplies no evidence, and evidence is the entire transaction. So the question you are really trying to answer is not which idea sounds most impressive. It is which idea you can finish, film and explain. Those are different lists, and the second one is far shorter. Rank that list and every later decision gets easier.

What counts as a robotics portfolio project in plain terms?

A robotics portfolio project is any build where something senses the world, decides what to do, and moves, packaged so a stranger can watch it happen without owning your hardware. That definition stays deliberately loose about scale, because scale is not what separates projects that land from projects that do not. A camera on a servo bracket that keeps a face centred in frame qualifies. A simulated forklift that lifts a pallet off a shelf qualifies. A script that reads a log file and plots joint angles does not, because nothing moved and nothing was uncertain. Robotics carries one property that makes portfolios harder here than in web or app work: the reviewer does not have your motors. Source code alone proves almost nothing, because nobody can run it. The packaging is therefore not decoration, it is half the artefact — a video, a simulator scene somebody can launch, a list of what hardware is required, and a plain account of what still goes wrong. A build without that packaging is private work rather than a portfolio piece.

What kinds of robotics project can you actually build?

You have roughly eight kinds of project available, and they differ mostly in how long they take and how much they distinguish you, rather than in how hard they look from outside. You can rebuild a tutorial and publish the result. You can build a simulated robot that navigates or grasps. You can build a small physical machine, however modest. You can write and maintain a driver for one awkward device. You can contribute fixes to a project other people depend on. You can reproduce a research paper in simulation. You can write up your part of a team build honestly. And you can build around the multi-language reality of robot software, which is where the framework choice starts to matter: ROS 2 is the vocabulary most of the field speaks and carries the largest collection of existing robotics code anywhere, while HORUS is an open-source real-time robotics middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between processes on one machine are never serialised. Read the table as descriptions rather than a ranking.

What should you build if you are a student with no work experience?

Build the thing your coursework cannot prove, which almost always means one machine that ran outside a supervised lab session with nobody standing next to it. Your degree already establishes that you can do the maths and follow a lab sheet, and every classmate applying alongside you has the same evidence with the same package names. What none of them tend to have is a machine that survived a week of being switched on by somebody else. So take the coursework robot and push it somewhere the module never went: run it for an hour instead of a demo minute, give it a start-up that recovers from being placed in the wrong spot, handle the sensor that occasionally answers with nothing. Then write down the failure that cost you three days, because that write-up is what an interviewer will actually ask about. If you are on a competition team, isolate your part precisely and describe the interfaces you owned. The work that separates students is rarely more advanced, it is simply less supervised, and there are routes to that experience outside a job worth knowing about.

What can you build with the hardware already in your room?

More than you expect, and the honest floor is a laptop and nothing else. A webcam, two hobby servos and a bracket is enough for a machine that tracks something and moves to follow it, which is a complete sensing-to-motion loop with real timing in it. A small wheeled base with an encoder on each wheel covers similar ground for the price of a takeaway. Neither needs an arm that costs as much as a car. If your budget is genuinely zero, simulation is a legitimate route rather than a fallback, and you can get surprisingly far without buying a robot. What ruins a simulated project is a world where nothing is uncertain: perfect sensing, perfect timing, nothing unexpected ever. Add noise to the readings, delay the perception path, put an obstacle where the plan did not expect one, then write the recovery and film it. A reviewer watching a simulated robot handle a disturbance learns more about your judgement than one watching a real robot execute a scripted motion without a wobble.

What if you only have a few free weekends?

Do not start a new robot. Finish and document the strongest thing you have already half-built, because nearly all the untapped value in your existing work sits in presentation. Two weekends of finishing beats two months of starting, and the arithmetic is not close. Pick the project you feel worst about abandoning. Get it to run from a cold start without you touching anything. Film that, uncut. Write the opening line of the README as a plain sentence saying what the machine does, then the video, then the hardware or simulator needed, then the exact commands, then a section about what does not work yet. Pin it. Hide the abandoned experiments. If you still have a weekend left, write a short post about the hardest bug and how you tracked it down, then link that from the README. Most people in your position skip all of this and start something new, which is precisely why so many beginner projects stall and why finishing is such a cheap advantage.

What should you build if you have never made a motor move?

Build one sensor, one actuator, and a loop between them, and get it running before you touch any framework at all. The smallest complete robotics project reads a value, decides something, moves something, and repeats on a rhythm, and it teaches more in a weekend than a month of watching videos. A distance sensor and a motor that stops the machine before it hits the wall is an entire system in miniature, with all the real problems present in small form. Once that works, add the things that make it a machine rather than a demonstration: what happens when the sensor answers with nothing, what happens when you unplug it mid-run, what happens when it starts in a strange position. Those questions are the job. Only after that should you reach for a framework, and reach for it because you now have two programs that need to exchange data, not because a listing mentioned a name. Learning a framework before feeling the problem it solves produces someone who can recite commands and cannot defend a single decision.

What does an unimpressive project look like from the other side of the screen?

It looks like effort with no evidence attached. The reviewer sees a repository with a promising name, a README consisting of the framework's default text, a folder structure suggesting genuine work, and absolutely nothing proving the machine ever moved. No video. No photograph. No note about what hardware it needs, so there is no way to tell whether it ran on anything or only compiled. Commits all arriving in one push, which reads as a copy whether or not it was one. A list of features in the future tense. Then, at the bottom, a line saying the project is on hold. None of that means the work was bad, and that is the frustrating part — the underlying build is often genuinely good. But the reviewer has minutes and a queue, and every gap costs a little goodwill until the tab closes. A weaker project with a video beats a stronger one without, consistently, and the way employers read a profile page makes that gap wider than it feels.

What do you give up by chasing the project that impresses?

You give up breadth, speed and safety, and those costs are real rather than imaginary. One deep project on a wheeled base says nothing about manipulation, so a team hiring for arms has less to hold onto. It concentrates your risk: if the build stalls two-thirds through, you have nothing, whereas three small projects always leave something on the page. It takes long enough that you cannot chase an opening you saw last week. And it will teach you one domain thoroughly at the expense of the others you might have sampled. Those are genuine trade-offs, and they are usually still worth accepting, because the alternative fails in a worse way. Three shallow projects all say the same sentence, which is that you can follow instructions. Depth produces the stories that conversations run on: the week you spent discovering the readings were stale, the redesign after the first structure stopped holding, the choice to move one component into another language. The sensible hedge is not more projects. It is one deep project plus a few merged fixes elsewhere.

When is ROS 2 the better choice?

ROS 2 is the better choice for most portfolio projects, and being straight about that matters more than being interesting. Listings name ROS 2 constantly, interviewers ask about nodes, topics and transforms because that is the shared vocabulary, and a project built that way needs no explanation from you before a reviewer understands its shape. ROS 2 also wins outright on substance for entire categories of build. Anything involving mapping, navigation, motion planning, or a sensor whose only usable driver ships as a ROS 2 package is a ROS 2 project, because rewriting that groundwork yourself is not a weekend, it is a career. If you have never chosen a framework before, ROS 2 is where the tutorials, the answered questions and the people are. HORUS is not the answer when being recognised quickly is the objective. The division of labour is simple enough: build the project that speaks the field's language first, and whether ROS 2 is worth learning for a job has a blunter answer than the debates suggest.

Do you need an original idea before anyone will be impressed?

No, and here is why: novelty is not what a reviewer is testing for, and treating it as the bar keeps people stuck at the idea stage for months. What gets read is the presence of decisions. A pick-and-place demonstration has been built ten thousand times, and yours becomes interesting the moment the gripper misses and the machine notices, retries, and gives up gracefully on the third attempt. Nobody has built that version, because that version only exists once somebody has run the thing enough times to see it fail. Originality lives in the failure handling, the recovery, and the honest write-up, not in the premise. There is also a cost to chasing novelty that people underestimate: an unusual idea has no tutorials behind it, so you spend your limited weekends on plumbing nobody will ever ask you about. A familiar project taken two steps past where the guide stops is a better use of the same time, and it is far more likely to reach a state where you can film it.

Does a polished video make a weak project look strong?

Partly, but not the way you think. Presentation genuinely moves the needle, and a project with a video will beat an equivalent project without one nearly every time, so the instinct is correct. Where it goes wrong is in the kind of polish people invest in. Fast cuts, music, motion graphics and a highlight reel of best moments all read as compensation, because an experienced reviewer knows that a montage means most of the attempts were unusable. What actually persuades is unglamorous: one continuous take, the machine starting from a dead stop, real-time speed, and at least one moment where something does not go to plan and the system deals with it. That footage is harder to produce than a montage, because you have to make the machine reliable enough to survive an unedited minute. Which is the point. The video is not marketing wrapped around the project, it is the proof the project works, so effort spent making the robot survive the take beats effort spent editing around the takes where it did not.

What changes as the robot you are building gets more demanding?

The number of programs goes up, and that is when your project stops being about algorithms and starts being about how the parts talk to each other. Early on, everything lives in one loop and one file, and the hard questions are geometry and control. Then you add a camera, and suddenly perception wants to run at its own rate while the motors need commands on a strict rhythm. Then you add a model that thinks slowly, and the arm must keep holding position while it does. At that point you are making architectural choices, whether or not you notice: which parts share a process, what happens when one falls behind, whether a late message is worth using or should be dropped. This is where a portfolio project starts to resemble real work, and it is also where interviews get interesting, because those decisions are yours and defensible. It is also the moment when framework choice stops being cosmetic, because holding a control rhythm steady while a heavy program runs alongside is exactly what middleware is for.

How do you decide which project to start this month?

Write down the three ideas you keep returning to, then strike out any you cannot finish, film and explain, and build whatever survives. That test takes an evening and eliminates most of the paralysis. Apply it strictly. Finishing means running from a cold start without your hands involved. Filming means a continuous take you would show a stranger. Explaining means you can name the hardest problem you expect to hit before you begin, and if you cannot, the project is too easy to be worth the weekends. Then check the idea against what you want next: if you are aiming at a specific team, mirror the tools that team publishes; if you are aiming broadly, pick the domain appearing in most of the listings you would genuinely accept. Keep the scope small enough that the interesting part arrives early rather than in month four, because you will lose interest before month four, and an unfinished project earns exactly what no project earns.

Decide by situation rather than by ambition:

• If you are applying within weeks -> finish and film what you already have, because presentation is the cheapest value available to you.
• If your budget is zero -> a simulated build with noise and failures in it, because disturbance is what shows judgement.
• If you have never made hardware move -> one sensor, one actuator, one loop, because everything harder assumes you have felt that.
• If you want a project unlike everybody else's -> a multi-language machine on one board, because Python and compiled code cooperating is a story with decisions in it.
• If a specific team is your target -> whatever that team publishes, because being legible to five people beats being unusual to five hundred.

When two ideas stay level, judge the tools you would build them on against the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Take the option that loses on the fewest. If your next project puts perception in Python and a control loop in a compiled language on one small board, star HORUS on GitHub so it is in your list when you start building.