How to Make a Robotics Project Explainer Video
Footage shows what a robot did. A drawn explainer shows what it was thinking: the map, the plan, the conflict it avoided. How to structure a robotics project video around the decision loop, with a scene by scene example for a warehouse robot fleet.
By openCanviz • October 17, 2026
8 min read
To make a robotics project explainer video, build it around the robot's decision loop (sense, estimate, plan, act) rather than around the hardware. Open with 10 to 20 seconds of real footage so viewers know the robot exists, then switch to drawn scenes that show what footage cannot: the map the robot holds, the path it planned, the other robot it had to wait for, and the failure you designed around. Write it as 450 to 900 words of narration for a three to six minute video, one paragraph per scene, with every number your evaluation actually measured. Drawn diagrams explain. Footage proves. A good robotics explainer uses both.
Why footage alone does not explain a robot
A clip of a robot driving across a floor tells the viewer almost nothing about the project. It drove. Was it following a line, replanning around an obstacle, or replaying a recorded path? From the outside they look identical.
Everything interesting about robotics happens inside the robot's state: the occupancy grid, the pose estimate and its uncertainty, the planned trajectory, the cost it assigned to each option. None of that is visible on camera. Teams usually try to fix this with an RViz screen capture, which is accurate and unreadable to anyone who did not build it. A drawn explainer sits between the two. It shows the internal state, simplified to the parts that matter for the point you are making.
| What you want to show | Real footage | Visualiser capture (RViz, Foxglove) | Drawn explainer |
| The robot works in the real world | Best | Weak | Weak |
| What the robot believes about the world | Cannot | Accurate but dense | Clear, simplified |
| Why it chose one path over another | Cannot | Partly | Best |
| A failure case and how you handled it | Hard to stage safely | Good if logged | Best |
| The system architecture | Cannot | Cannot | Best |
So the practical shape is: footage at the start and end, drawn scenes in the middle, and visualiser captures only if your audience is other roboticists.
Who the video is for changes what goes in it
A capstone or demo day panel wants to know what you built, what was hard, and how you measured it. Lead with the problem and spend time on the hard part.
Recruiters and hiring managers want to know what you personally did. Say it. "I wrote the multi-robot planner and the deadlock detector" is worth more than ten seconds of footage.
Investors or a non-technical sponsor want the outcome in their terms: picks per hour, error rate, what a human no longer has to do. Keep the algorithms to one sentence each.
Other robotics engineers will forgive less polish and want more depth. Show the actual cost function, the real failure rate, the log plot.
Pick one. A video that tries to serve a panel and an investor at once serves neither.
Worked example: coordinating a warehouse robot fleet
Here is the scene list for a five minute explainer of a student or startup project: twelve mobile robots that carry shelving pods to pick stations on a grid warehouse floor, coordinated by a central planner.
| Scene | What is drawn | Narration (key line) |
| 1. Footage | Real clip, 15 seconds, four robots moving pods | "Twelve robots, one floor, and none of them is allowed to stop another." |
| 2. The job | The grid floor from above, pods as squares, three pick stations on one edge | "An order comes in. Some pod holds the item, and some robot has to bring it to a station." |
| 3. Localisation | A robot reading a marker on a grid cell, its position snapping to that cell | "Each robot knows where it is by reading a marker on the floor at every cell, so its position error never grows beyond one cell." |
| 4. Task allocation | Three idle robots, one pod, dotted lines with travel times; the nearest one is assigned | "The planner assigns each new task to the robot that can reach the pod soonest, not the one that is closest in a straight line." |
| 5. Single robot path | A* search spreading across the grid to the pod | "On its own, a robot finds its route with A* on the grid, which takes under a millisecond." |
| 6. The real problem | Two planned paths crossing the same cell at the same time step | "The problem is not one robot. It is two robots that both planned to be in cell D7 at second 14." |
| 7. Reservations | A table of cells and time steps filling in as each robot plans | "We plan robots one at a time in priority order. Each one reserves the cells it will occupy at each second, and the next robot plans around those reservations." |
| 8. Deadlock | Two robots facing each other in a one-cell aisle, neither able to move | "Priority planning can still deadlock in narrow aisles. We detect a cycle in the wait graph and send the lower priority robot back one cell." |
| 9. Results | A bar chart: picks per hour with and without reservations | "With reservations, the fleet went from 210 to 340 picks an hour in simulation, and from 9 collisions per thousand tasks to zero." |
| 10. Footage | Real clip of the narrow aisle case being resolved | "Here is that deadlock rule on the real floor." |
Three things make this work.
Scene 6 is the turn. Everything before it is setup. A good robotics explainer names the hard problem out loud and then solves it on screen. Without that scene the video is a list of components.
Scenes 7 and 8 show the internal state. The reservation table and the wait graph are invisible in footage, and they are the actual contribution.
Scene 9 uses measured numbers. The figures above are an illustration of the shape. Use yours, and say whether they came from simulation or hardware. Panels ask, and the honest answer is always the better one.
Writing narration for a robotics audience
Say what the robot knows, not what it does. "It drives to the pod" is footage. "It plans a path that avoids every cell another robot has reserved" is the explanation.
Give one number per scene. Planning time, localisation error, picks per hour, battery margin. Numbers make a claim checkable.
Name the algorithm, then say it in plain words. "Conflict-based search, which means the planner finds each robot's best path, looks for the first collision, and splits the problem in two at that collision." The name is for the experts. The plain version is for everyone else.
Show one failure. The case where the robot got stuck, the sensor reading that fooled it, the edge of the map. A project with no visible failure looks like a demo, not engineering.
Make it
- 1
Write down the decision loop
In four lines: how the robot senses, how it estimates its state, how it plans, how it acts. That is your middle section.
- 2
Name the hard problem
One sentence for the problem your project actually solved. Build the script so that scene arrives a third of the way in.
- 3
Write one paragraph per scene
450 to 900 words for three to six minutes. One measured number per scene, and say whether it is simulation or hardware.
- 4
Draft the drawn scenes
In openCanviz, paste the script with Keep my wording and choose whiteboard, so grids, paths and tables draw as each step is described. Leave placeholder lines for the footage scenes.
- 5
Fix the diagrams against your system
Check every grid size, arrow and label. Drawn robotics diagrams often get directions and counts wrong. Edit those scenes one at a time.
- 6
Cut footage in at the start and end
Export the drawn video and combine it with your real clips in any video editor. Keep each clip under 20 seconds.
Common pitfalls
Opening with the parts list. Nobody needs to hear about the motor controller in the first minute. Open with the job.
Showing a cost map with no explanation. If you include a visualiser capture, say what each colour means, or redraw the part that matters.
Overclaiming from simulation. A planner that is collision free in simulation is not collision free on a floor with a dropped pallet. Say which one you tested.
Five minutes of ROS architecture. A node graph is interesting to people who will maintain the code. For everyone else, one scene with five boxes is enough, and a separate architecture explainer covers the rest. How to make an engineering architecture explainer for your team is the guide for that video.
If your project is written up as a paper or thesis, how to turn a research paper into a video summary covers taking the write up as the source. For animating a single diagram, such as the reservation table filling in, see how to make a diagram animate step by step.
Common questions
How long should a robotics project video be? Two minutes for a demo day reel or a portfolio link. Four to six for a capstone presentation or a technical audience. Past eight minutes, split it into a project overview and a deep dive on the hard problem.
Should I use my own voice? For a portfolio or a capstone, yes if you can. The panel or the recruiter is assessing you, and hearing you explain your own trade-offs helps. You can replace a generated voice with your own recording scene by scene.
What if the robot never worked on real hardware? Say so and make the video about the simulation. A clear explanation of a well-designed planner tested in simulation is a stronger video than shaky footage of a robot that half works.
Can I explain the maths? One equation per scene at most, spoken in words as well as shown. A cost function with three terms is fine. A full derivation belongs in the report.
Find your scene 6 first
Before writing anything else, write the one sentence that names the hard problem your robot solves, the moment two robots want the same cell at the same second. Build the script backwards from it. It is free to start.
Turn any concept into an animated explainer
Type an outline, get a narrated, animated whiteboard video in minutes. No design skills, no timeline scrubbing. Free to start.
Keep reading
A public research video is not a shorter paper. It leads with why anyone should care, states one finding in everyday words, says plainly what it does not mean, and runs two to three minutes. A method, a jargon table, a worked script on sound and plant growth, and the checks to make before posting.
PowerPoint, Keynote, Excalidraw with excalidraw-animate, Figma, After Effects, Manim, Mermaid and openCanviz all animate diagrams, but they are good at different jobs. A fair comparison by what you start from, what you get out, and how long a two-minute diagram takes.
A diagram that builds should appear in the order you explain it, not the order it was drawn or laid out. Here are the build orders for flowcharts, architectures, sequences and loops, a worked password-reset flowchart, and how to do it in slides, code or a narrated tool.
Screen recordings are right for showing a tool. For explaining a concept such as OAuth, a drawn, narrated tutorial is faster to make, easier to follow and does not go stale when the UI changes. How to script one, with a scene by scene OAuth example.