Building a robot for an open workshop

General guidance and one project's case, kept apart on purpose. Only the first travels to your project unchanged.

This is a design record, not a build manual. Robotics is too wide a field for one project to write a handbook of it, so the book does something narrower: it follows one robot through five generations and records, for each decision, what was decided, why, and what we know now that we did not know then.

How the book is organised

Four parts. Part I is deciding what the robot is for, and the four earlier robots that taught us the answer. Part II is the brain: the speech pipeline, the language model, and the measurements that had to be made before V5 could be built. Part III is the body, largely still in design, and the safety and privacy work that has to come before it. Part IV is method and what comes next. A checklist, the open items and the list of references close the book. V0 to V5 name the robot's generations throughout; chapter 02 opens with a timeline and a table of all of them.

Two kinds of claim

The running text is general; it should hold for any workshop robot. Where a principle meets a concrete decision or number from Hynebot, it is set apart in a box, so the two kinds of claim cannot be confused. There are four kinds of box:

How to read the numbers

Every figure carries a small reference key that points to its entry in the References, grouped by kind: our own measurements, our own documents and code, theses and conference papers, and published literature. The text stands on its own; the key is there for when a figure matters to your own decision. A number without a key is marked as an estimate. Language-model quality scores are on a 0–5 scale unless stated otherwise. Where the project's own sources disagree, the disagreement is listed under Open items rather than resolved silently.

Where this comes from, and what that limits

The book is written out of one project's material: a 2020 conference paper, requirement lists and safety tables, three theses, a build report, source code from four generations, the V5 measurement campaign of 3 360 language-model answers, and safety and privacy memos. The language-model results rest on one computer, one question set and one automated judge; chapter 10 lists their limits. The history of V1 to V3 is reconstructed from documents, and parts of it are thin. And no student has yet used V5. Chapter 11 returns to that, because it is the most important limit in the book. What transfers is the order of decisions and the ratios between options; individual scores and seconds do not.

This is the second book in the JHC Platform Series, open design records of the J. Hyneman Center's long-running platform projects; the first is on the Ukkonen electric race motorcycle. The book is meant to grow with the project: a superseded figure is replaced in place, and the change is recorded in the revision notes.

“A robot for the workshop” is three different design problems. Each one gives you a different machine, and each one needs a different test of success.

A race motorcycle has one metric nobody can argue with: lap time. A workshop robot does not, and that is the first thing to deal with, because a project without a metric will be steered by whatever is easiest to improve that week. In our experience that is usually software.

Three kinds of useful

You can build a workshop robot to be useful in three ways, and they lead to three different machines:

The three overlap, which is exactly why it is easy to believe you can have all of them. A presence robot needs mobility and a screen. So does an assistant. A demonstration robot needs both of those plus something that moves in an interesting way. So the requirement list grows, and nothing on it looks unreasonable on its own.

The viewer cannot tell whether the motion is autonomous

For the demonstration purpose there is a specific trap, and it is worth naming because engineers walk into it on pride. Full autonomous navigation is the hardest and riskiest part of a mobile robot. It is also the part a visitor cannot see. A robot that drives up to you because an operator steered it looks exactly like one that planned its own path. What visitors react to is that it moves, that it speaks their language, and that it comes when called. None of those requires a map of the building.

The subsystem that grows fastest will try to become the product

The second trap is quieter. In a robot with a language model inside it, the language-model work is the fastest thing to iterate on. It runs on a desk, needs no parts, and produces numbers every day. Left alone it drifts towards a desktop voice assistant, and a desktop voice assistant is one step from a generic chatbot. That teaches students nothing about building machines, and it is not what a workshop is for.

What the metric is, for us

For V5 the lead purpose is assistance with mobility: a robot that drives to where a student is working, answers questions about the workshop's machines correctly in Finnish or English, and can be extended by students. Presence remains. V4 serves it today and stays a telepresence robot; V5 is built to serve it as well, as a telepresence robot that can also act on its own. Demonstration follows from the other two if they are done in the open.

The metric that follows is uncomfortable because it cannot be measured on a desk: people who did not build it use it, and what it tells them is right. As of this revision, no student has used V5. Every number in Part II is a measurement of parts of the system under controlled conditions. That is necessary, and it is not the metric.

What we said in 2020, and what changed

The purpose was written down once before, in the JHC team's 2020 conference paper. It is worth quoting how clearly it drew the line. The telepresence robot, it said, does not function like a programmed robot that would require artificial intelligence: “the aim is not to help at some routine tasks, such as safety and lab instructions, answering the same type of questions over and over, monitoring students at work”. It is a camera eye and an arm connected to a microphone, a loudspeaker and a moving platform, all controlled remotely, a tool that wakes up only when someone connects to it. SEFI

V5 is being built to do precisely the routine tasks that paragraph excluded. That is not a contradiction to hide. In 2020 no language model that could run on a robot answered a technical question correctly in Finnish; in 2026, chapter 05 shows, several do. The presence purpose did not go away: V4 serves it, and V5 keeps it alongside the new one. What changed is that a second purpose became possible, and the lead purpose of the newest version moved with it.

The same paper sets out the design philosophy behind the presence purpose, and most of it still holds. Since the robot is a surrogate for human interaction, the default should be to replicate what a person would experience if they were there, starting with low latency and an image good enough to see details on the bench. It should have something equivalent to a head that can meet people face to face, ideally movable from desk height to standing head height, with head and base movements choreographed so that the operator's intent is visible. But it should capture the intent rather than copy the human literally: a screen with a face on it is better than a mechanical rubber face, which lands in the uncanny valley. And a robot need not stop at human abilities; it can see more, hear better or draw a straighter line than a hand can, to balance what it will never do, such as touch and smell. SEFI

Each generation removed something the previous one could not carry. The one that got used was the one that did the least.

It would be tidier to present V1 to V4 as steady progress. It was not. Each version was built by different people, usually as a thesis or a summer job, and each one inherited a machine that did not quite work and a pile of reasons why. What they have in common is more useful than what separates them: nearly every one of them made the robot simpler, and the working one is the simplest.

The generations at a glance

V0 is the student course prototype of 2019–2020 that preceded the robot the project later called V1. The book counts it as a precursor rather than a generation, which is why it speaks of five generations. They are generations of one idea, not refinements of one machine: several of them started almost from zero.

References: V0 SEFI; V1 NUTJUV; V2 V2R; V3 V3; V4 V4; V5 STATRISK. Dashes mark figures that were never recorded; V2 and V3 have since been dismantled, so theirs cannot be recovered.

V0, 2019–2020: a course project with a sister robot

The first robot was not a thesis. It was built by student teams as the project work of four courses in mechanical and electrical engineering: analogue signal processing, electronics project work, systems engineering project work and technical design. The workshop staff acted as the client, setting the requirements from the user's point of view and leaving the students to re-examine them. The intention from the start was a relay: a modular, low-budget first version to prove the concept, then successive versions built by new groups on top of the previous ones' work. SEFI

The requirements that later became V1's list were first written here: a 90 cm door, aisles in a lab, a lift with a guardian, buttons and switches, two hours on a battery, recharging without special training, collision prevention, and a camera image good enough to see details of the work being guided. Opening doors was left out on purpose, as too demanding for a first robot.

The paper's own conclusions are as useful now as then. Find out exactly where latency comes from before optimising anything, because it may have nothing to do with the robot's processors. Give students a stronger role as testers, not only builders, and collect user experience systematically between rounds. And the project raised a question that this book still has not settled: whether a workshop should teach rapid, iterative product development or manageable, clearly planned projects. A robot built by successive student teams cannot be run as a linear plan without skipping the development steps that make it useful. SEFI

V1, 2020–2021: everything at once

V1 was designed as a master's thesis by Perttu Juvonen between September 2020 and March 2021, from the requirement list in chapter 01, continuing where the course project had left off. It is a remarkable piece of work for six months. The structure changed from aluminium to Nordic birch plywood, cut on a CNC router, chosen so that anyone with a router could build one and so that it could ship flat. The robot stood 137 cm tall on a 61 × 56 cm footprint, weighed 44 kg, and carried a Dorna 2 arm on a vertical carriage, an Intel RealSense depth camera and a 10-inch touch screen on a tilting neck, an Intel NUC running ROS 2 (Robot Operating System, a widely used software framework for robots), and a 24 Ah e-bike battery. NUTJUV

Omnidirectional movement was a requirement, and Juvonen chose a modified swerve drive: three wheel modules, each with one motor to steer and one to drive. That is six motors and a six-axis controller for a robot that mostly needs to go forward, turn and occasionally slide sideways through a door. His own conclusion in the thesis is the most useful sentence written about V1: that many features which are easy to implement mechanically need a significant amount of work on the software side, and that enough resources have to be allocated for it. JUV

V2, summer 2023: making it look finished

V2 was a rebuild of V1 by two of JHC's summer research assistants, Jake Cumens and Jethro McLean, in the summer of 2023. Its brief was mostly visual: no visible screws, no laser soot, tidier joints, a centred screen, the speaker hidden. That brief was met. Rails were glued into recesses, the base cover got a new flex pattern, the charred edges were sanded away. The more interesting findings were the ones nobody asked for. V2R

V2 also dropped the depth camera as unnecessary for what the robot was doing at the time, and noted that the arm's control unit probably had a faulty module. The rebuild was not fully finished. In parallel, a student, Robert Hämäläinen, wrote the control software for the V1/V2 drivetrain between 2023 and early 2024, talking to the motor controller over its native protocol and to a browser over WebSockets. CTRL

V3, 2024–2025: the simplest thing that moves

V3 came out of Sachintha Alwis Weerasinghe's 2024 master's thesis, which took the telepresence robot back to first principles with a systematic design method. It arrived at the simplest mobile Hynebot yet: an ESP32 microcontroller board driving two DC motors with Hall sensors (which count wheel revolutions) through a hobby H-bridge motor driver, a swivel caster at the front, remote control over MQTT (a lightweight messaging protocol), and video through an ordinary conferencing app on a tablet fixed to the robot. ALW

Miro Hakuli's 2025 thesis built a remote-control system for the V1-derived robot: a server between user and robot, socket.io (a library for live messaging between browser and server), and a browser interface. Its requirements came from interviews with the people around the project, and the one they stressed most was security: nobody should be able to move the robot without permission, and only one person at a time. Everything was tested except the motors themselves, because the robot had problems that prevented it. HAK

The V3 prototype from the 2024 thesis worked only on the local network. Real remote use, over a 4G connection from anywhere, was added at the end of 2025 as a JHC project, after Hakuli's thesis, together with a Raspberry Pi camera and live video and control in a web browser. With that, V3 did one thing, moving under remote control from somewhere else, and it did it. V3

V4, 2026: the one that got used

V4 is the version in service today. It kept the plywood tower and screen, and replaced almost everything underneath with the plainest parts that would do the job: a ready-made omnidirectional base the project received in 2024, with four omni wheels on four motors and two dual-channel Roboteq controllers; an Intel NUC running a handful of small Python services instead of ROS; three wide-angle USB cameras (forward, down at the floor in front of the robot, and rearwards); a USB microphone and speaker; a 24 V lithium battery; and a 4G router on board. It is driven from a web page, with keyboard control on a laptop and a touch joystick on a phone. The software was written in early 2026 largely by one staff member with an AI coding assistant, after the code left by several student generations proved too scattered to revive; chapter 10 says more about how AI assistance was used. V4

What V5 inherits, and what it does not

In spring 2026 the decision was made to keep V4 exactly as it is, as a working telepresence robot, and to build V5 alongside it as a new platform that keeps the telepresence role and adds the assistant role. V5 inherits V4's drive kinematics and its drive, camera and display services as a starting point, the plywood-and-standard-parts philosophy from V1, the four-motor omni drive that V2's report pointed to, and the lesson from every version that the software is where the time goes. It does not inherit V1's arm-on-a-carriage layout, V1's middleware, or the assumption that the first body has to do everything. V4K

One question asked once tells you about that question. The model we recommended after the first afternoon was not the one the data chose.

V5 had to speak Finnish and English. Roughly half of JHC's users are international students, and the other half deserve to be answered in their own language. The robot also had to run everything locally, for reasons chapter 07 sets out, which put the whole language model on one NVIDIA Jetson AGX Orin, an embedded computer built for robots, with 64 GB of memory shared between processor and graphics. So the question was concrete: which openly available language model, compressed to fit that memory, gives correct technical answers in both languages fast enough to talk to? V4K

None of that could be looked up. Published comparisons of language models are almost all in English, run on data-centre hardware, and score general knowledge rather than whether a model knows which way the filament goes into a particular printer. There was no table anywhere that said how a model compressed to fit a Jetson answers a safety question in Finnish. The choice also fixes everything downstream: the memory a model needs decides the computer, the computer decides the battery and the mass, and the time it takes to answer decides whether a conversation is possible at all. So the first months of V5 were measurement rather than building, and this part records what was measured and what it changed. Chapter 10 explains why the results are published here rather than in a journal first.

The protocol

We wrote 40 technical questions, each in Finnish and English, in six categories: general technical knowledge (10), JHC's own machines such as the Prusa MK4 printer, the laser cutter and the soldering station (10), scientific reasoning (5), workshop safety (5), everyday descriptive language (5) and demanding technical concepts such as G-code, mesh bed levelling and PID control (5). Before any model saw them, each question was given a list of facts an acceptable answer must contain and a list of red flags, claims that would be wrong. PLAN

Every model answered every question three times, at temperature 0.7, on the Jetson, through Ollama (both explained in the box above). The first run, Study A, covered eight models from 7B to 70B and took 28 hours 43 minutes over 12–13 May 2026: 1 920 answers, of which two timed out. A controlled quantization run added 480, and Study A2 at the end of May added 960 from a newer generation of models. In total 3 360 answers were generated on the robot's own computer. STAQ34A2

Questions

40 × 2

Repetitions

3

Models

11

Answers

3 360

Hardware

1 Jetson

Who scores 3 360 answers

Not a person. Every answer was scored blind by a separate, larger model acting as a judge: Claude Sonnet 4.6 through Anthropic's API, which saw the question, the answer, the acceptance criteria and the red flags, but not which model had answered. It scored factual accuracy, language fluency and completeness from 0 to 5 and listed every incorrect or invented claim it found. The prompt is reproduced in full below, because a judge is only as good as its instructions and anyone checking our numbers needs them. JUDGE

Of the Study A answers, 1 918 were judged automatically, one was scored by hand after the judge declined a harmless question, and the two timeouts have no score. The failures we did see were mundane: the judge wrapping its JSON in a code block, or running out of output length on very long answers. Each was fixed and re-run, and every final score was checked to lie in the 0–5 range. STAT

Checking the judge, and then checking the humans

An automated judge has to be checked against people. We drew a stratified sample of 60 answers, ten at each accuracy level the judge had given and half in each language, and had three people score them for factual accuracy without seeing the judge's scores or the model names. One of them belonged to the project team; the other two were given minimal instructions and no hypotheses. IRR

Source: IRRA1. Rater 3 had the most experience with the technical domain.

Read naively, a Fleiss κ of 0.12 is poor. Read properly, the judge agrees with the humans about as well as the humans agree with each other, and with the most experienced rater it reaches what is conventionally called substantial agreement. Published work on multilingual automated judges reports Fleiss κ around 0.3 on average and as low as 0.1 for some languages, so this is a hard task for everyone, not an unreliable judge. FULIU

One step of extra compression destroyed a large model's Finnish and left its English untouched. Guidance based on English benchmarks does not transfer.

Everyone who runs a large model on edge hardware quantizes it. The common guidance, that four bits per parameter costs very little quality, comes almost entirely from English benchmarks and from translation tasks at four bits. It rarely isolates one morphologically rich language, one that builds words from many endings as Finnish does, at three bits, which is where a 70B model has to go to fit comfortably in 64 GB. MARCHBORG

Study A contained exactly that case, and it was the most striking result in the data. The largest model, Llama 3.1 70B at three bits, wrote good English, judged at 3.48 for accuracy, and fell apart in Finnish at 0.48. Its Finnish answers were a quarter the length of its English ones, 18 % of them were under 100 characters or off-task, and at 1.8 tokens per second it took almost three minutes to produce each one. It was the worst model in the study in Finnish and the slowest. The collapse was deepest exactly where the robot needs it most: on the questions about JHC's own machines, its Finnish answers averaged 264 characters, the shortest of any model in any category. A1STA

That result alone cannot separate two explanations. Either this model family is weak in Finnish, or three-bit compression is the cause. So we ran the same 70B model again at Q3 and at Q4, on the same questions with the same settings, changing only the quantization.

The effect is not carried by a few questions. Taking each question as the unit, so that three repetitions of one question are not counted as three pieces of evidence, 36 of the 40 Finnish questions improved from Q3 to Q4, one got worse and three were unchanged. The median improvement per question was 1.67 points (95 % bootstrap interval 1.00 to 2.33, a confidence range found by resampling the questions). The matched-pairs rank-biserial correlation, an effect size from −1 to 1 where 1 means every question improved, was 0.99 (0.97 to 1.00). In English the same comparison gave 8 better, 11 worse and 21 unchanged, a median change of zero and a correlation of −0.14 with an interval spanning zero: no effect. A1

Two mechanisms, not one

The controlled run also separates two things that the first result mixed together. The collapse from 2.22 to 0.46 is caused by three-bit quantization, because nothing else changed. But even at four bits, the 70B model's Finnish (2.22) stays far below its English (3.58). That second gap is a property of the model family's Finnish, and quantization does not cause it and Q4 does not fix it. Other models in the study, several of them much smaller, did far better in Finnish at four bits (table in chapter 05).

What this does not show

This is one model family at one pair of quantization levels. The mechanism is consistent with published work showing that three bits is where measurable degradation begins and that the safe bit width depends on scale, but we have not shown that the threshold is general. CHANGKIM The two experiments that would strengthen it most are a smaller model at Q3 (Llama 3.1 8B at Q4 already scores only 0.61 in Finnish, which complicates the picture) and a repeat with greedy decoding (temperature 0), to separate the collapse from sampling noise at temperature 0.7. Both are listed under Open items.

Our first selection criteria measured how much a model wrote, not whether it was right. Architecture mattered more than size.

The full table

Eleven models, two runs. Study A models answered in May 2026; Study A2 re-ran phi4 as a baseline alongside three newer models so that the two runs could be compared. A1A2

Hallucinations are counted per answer with both languages pooled. All Study A models are four-bit except the 70B at three. References A1A2.

Three things stand out. English is easy: every model except the Finnish-specialised Poro scores between 3 and 4.3. Finnish separates the models by a factor of eight, and not in order of size. And the newest generation closed most of the gap: the three 2025–2026 models all score close to 4 in Finnish.

The criteria were wrong, and the data said so

Architecture beat size

For a robot, the answer has to arrive while the person is still standing there. In the same protocol the two newer dense 27B models took around two minutes of generation per answer on the Jetson: gemma3:27b averaged 126 seconds and qwen3.6:27b 138. The mixture-of-experts gemma4:26b, nominally the same size and with the best overall quality, averaged 29 seconds on the same long answers. Picking the biggest model that fits in memory is the wrong instinct on edge hardware; pick the architecture that uses only part of itself for each word. REPA2

Consistency is its own axis

A robot that gives a different answer each time you ask erodes trust even if every answer is acceptable. We measured it two ways across the three repetitions: how much the answer length varies (the coefficient of variation, standard deviation as a percentage of the mean) and how much the wording overlaps (ROUGE-L, the share of words that appear in the same order in two answers, from 0 to 1). The two agree well (rank correlation, Spearman ρ, of −0.79 across the eight Study A models), and neither follows model size. REP

The instability sits almost entirely in Finnish. In English every model varies by 5–22 %; in Finnish the range is 6–64 %. An evaluation run only in English would not have seen the problem at all. The two measures can also disagree in a way that matters. phi4 is the second most consistent Study A model by answer length, yet its judged accuracy varies more from one repetition to the next than any other Study A model's (standard deviation 0.49 points against 0.29–0.48 for the rest): it says the same amount each time, but not the same thing. And the controlled 70B run shows that quantization explains part of the instability but not all of it. Going from Q3 to Q4 reduced the length variation from 41.9 % to 30.3 %, still far above the stable models. REP

The phi4 baseline, run twice three weeks apart after an update of the model runtime, reproduced to within 0.3 points on every measure, which is the evidence that the two runs can be compared at all. A2

What changed between generations

Two families appear in both runs. Qwen went from 1.21 in Finnish accuracy (2.5, 14B) to 4.02 (3.6, 27B). That jump is real but it mixes a new generation with a model twice the size, so it is not a clean generational effect. Gemma, at a constant 26–27B, went from 3.07 to 3.87 to 3.82 across three generations, with hallucinations falling from 1.62 to 1.13 to 0.86 per answer. The practical reading is that a Finnish-speaking robot built in 2024 would have needed a Finnish-specialised model or a larger computer, and one built in 2026 does not. A1A2

A robot standing next to a machine and answering fluently and wrongly about that machine is a hazard. Letting it read the manual first fixes most of that.

V5's retrieval runs on the Jetson: the multilingual-e5-base embedding model, a local ChromaDB vector store (a database searched by embedding), and as the first knowledge base the Prusa MK4 printer handbook, 67 pages indexed one page per chunk. A Finnish question and its English equivalent land very close together in the embedding space (cosine similarity 0.939, where 1 would mean the same direction), so Finnish questions reliably find the right page in an English manual. Across six probe queries, three topics in two languages, the correct or topically correct page was in the top two results every time. That matters, because almost all machine documentation is in English and half the questions will not be. RAGIA2D

The first retrieval prototype, built with Mistral Small 24B before gemma4 was chosen, showed the qualitative pattern that the later test confirmed. With the manual, answers contained procedures that exist only in that manual: cleaning the print sheet with isopropyl alcohol, running mesh bed levelling, confirming with the rotary knob. Asked something the manual does not cover, the grounded model declined instead of inventing an answer. Without the manual it did neither. A2D

This is the same failure the human raters showed in chapter 03, one layer up. There, people scored fluent nonsense too high. Here, the model produces fluent nonsense about the very machine the student is standing at. An earlier comparison in the project had already shown that a 24B model with the manual beats a 70B model without it on device-specific questions. RAGI That finding is about quality. The load-cell answer is about safety, and it is the one that decided the design.

Retrieval substitutes for scale

Put the two findings of this part side by side and they point the same way. A large model compressed to fit the edge computer loses the minority language first (chapter 04). A smaller model that can read the documentation answers machine-specific questions that neither the large model nor its own memory can. On a fixed memory budget, capacity spent on retrieval buys more than capacity spent on a bigger model. That is the practical form, for a bilingual workshop, of the broader argument that small, suitably augmented language models are enough for most agent-like tasks. BELCAK

What retrieval does not fix

The prototype also showed three things retrieval cannot correct, and they are as important as what it can. A2D

• Antonyms sit next to each other. A Finnish question about loading filament retrieved the unloading page and the loading page at almost identical distances, 0.415 and 0.416, because the two pages share nearly all their context. Meaning-based search is weakest exactly where the meaning is opposite and the words are the same.
• Translation happens at answer time. The manual is English and the answer is Finnish, so the model translates as it answers, and it rendered at least one control name as a non-standard Finnish compound that appears nowhere in the source. Grounding fixes facts, not terminology.
• It trusts what it is given. If speech recognition mishears the question, retrieval faithfully answers the wrong one. Chapter 07 follows that failure through the whole chain.

Speech in, speech out, nothing sent anywhere, and every stage in between can fail on its own or pass a mistake on to the next.

Why nothing goes to the cloud

Three reasons, in order of weight. Privacy: a microphone in an open workshop hears people who never chose to talk to a robot. If audio never leaves the device and is never stored, most of the privacy problem does not arise (chapter 09). Independence: the university network blocks some services, the robot moves between networks, and a robot that stops talking when the connection drops is not a robot anyone relies on. The point of the exercise: showing that a capable, bilingual assistant fits on one board is itself part of what the workshop is demonstrating. The one exception during development was the automated judge in chapter 03, which ran on stored text answers, never on audio, and is not part of the robot.

Hearing and speaking

Speech recognition is faster-whisper with the small model on the Jetson's GPU. It does not install from the standard package on the Jetson: its engine, CTranslate2, had to be compiled from source with CUDA support (NVIDIA's platform for computing on the GPU). Speech synthesis is piper, with a male Finnish voice and a female English one. That asymmetry is not a design choice. There is no good open female Finnish voice, which constrains how the robot presents itself. STATPS

Errors travel down the chain

Each stage of the pipeline has its own benchmark: word error rate for recognition, precision for retrieval, judged accuracy for the model. Each benchmark assumes the stage receives clean input. In a working robot none of them does, and the failures we saw on the desk were not in any one stage. They appeared where the stages meet. A3D

The mitigations follow from the failures and each can be tested: recognition that reports its confidence and flags uncertain domain terms before they reach the model; a prompt that makes the model say when a word in the question looks wrong; re-ranking or hybrid word-and-meaning search to separate near-antonyms; and translating the retrieved passage as a separate step before the answer is formed. A3D

Traps worth knowing about

The rest of the software is deliberately plain. A router module decides per question whether to search the manuals, keeps the model loaded, and sets the thinking switch correctly for each model. Development happens on a laptop, code goes through a GitLab repository to the Jetson, and the robot's own network is kept separate from the university's production network, with the development machine between the two. ROUT

An omnidirectional base built from parts already on the shelf, sensing that sees all the way round, and an arm for gestures. The body above the base is not described here.

V5's body is still being designed, and this record does not describe its structure above the base. What is settled is the part JHC has worked out on its own account: the drivetrain, the sensing the base needs, and what the arm is for.

The drivetrain

V5 uses parts already on the shelf: four Nanotec DB43 brushless motors with 4:1 planetary gearboxes, 100 mm omni wheels, and four Electromen EM-356A-SBL motor controllers driven from the Jetson over a single RS-485 serial bus using Modbus, a simple industrial communication protocol. Raw geometry gives about 3.9 m/s at full motor speed, far too fast indoors, so the speed is limited in the controllers themselves, below the reach of any higher software layer. V4's omni-wheel kinematics carry over unchanged; only the motor-controller driver has to be rewritten. PSOV

Sensing, and the order the frame has to respect

An omni base moves sideways and backwards as readily as forwards, so the distance sensing has to see all the way round. A 270-degree scanner leaves a blind sector exactly where the robot can drive. V5 will carry a 360-degree navigation LiDAR, a laser scanner that measures distances all round, from the start, with a safety-rated scanner as a later addition, not a replacement. The frame is being drawn so that adding one later costs a bracket, not a rebuild: an Ethernet and 24 V route to the scanner mount, a swappable mounting plate, a reserved mass and volume, and a free dual-channel safety relay input. OVSTAT

The arm: gestures, not manipulation

V1 was specified around an arm, and V5 still has one: the Dorna Arm 2. Its software is ready. The key discovery was that its home position, with every joint resting against its hard stop, is not all zeros but 180, 180, −142, 135 and 0 degrees, which explained every alarm in the first tests. A safe parking pose one degree off the stops was established so that nothing drops when power is cut, and a complete demonstration sequence has been validated. DORNA

In V5's first year the arm makes gestures and nothing more. Handing people objects needs a gripper, and an industrial electric gripper weighs around a kilogram, a large share of what a small desktop arm can carry. Carrying things on a tray or a rack does the same useful job with a fraction of the risk. STAT

The risk assessment decides the emergency-stop topology, which is an input to the electrical design. The privacy memo decides that audio is never stored, which is an input to the software.

Safety was on the first requirement list in 2020. The course project already required the robot to prevent collisions on its own, with pedestrians and glass doors named explicitly, and its paper suggested a pleasant sound whenever the robot moves, so that people nearby know even if they are not looking, and geofencing, a virtual boundary, to keep remote operators out of places the robot should not go. SEFI The sound is now a line in V5's risk assessment. V1 added a table of hazards and mitigations mapped to ISO 12100, ISO 10218, ISO 13482 and ISO/TS 15066, and a rule that the robot stays under 60 V DC. No single standard covers a hand-built telepresence robot with an arm; Juvonen's thesis applied the relevant parts of several. That approach has not changed. The 2020 paper also asked a question that belongs next to the hazards: can a telepresence robot be misused in an educational setting, and how would that be prevented? SAFE1JUV

For V5, the risk assessment was written in June 2026, before the platform was designed, so that it could set requirements instead of auditing a finished machine. It identifies ten hazards across three phases (the desk unit, the mobile base, and the arm on the base) and rates each by likelihood and severity before and after mitigation. RISK

Scores are likelihood × severity, each 1–3. The full table has ten hazards. The battery's residual risk is accepted because its severity cannot be reduced technically; it is managed by prevention. RISK

The last row is the one a conventional machine-safety assessment would not contain, and it is why chapter 06 exists. A robot that gives advice at a machine can cause an accident without moving at all.

Privacy: the microphone hears everyone

A robot in an open workshop hears people who never chose to speak to it. V5's privacy memo turns that into system requirements rather than a policy. GDPR

• Audio is never stored. Speech is transcribed on the device and the audio buffer is discarded. This is a system requirement, not a habit.
• No identification. No speaker recognition and no face recognition; the camera detects object classes such as “person” in memory and keeps no frames.
• Logs describe interactions, not people. The interaction log records the question text, language, route, latencies and the manual page used, with no user identifier, and it stays on the device or in university-managed backup, never in the code repository.
• It listens only when asked. A wake word starts recognition, and the robot shows whether it is listening. Signs in Finnish and English say what is processed and where to read more.
• Research is separate. Any study with students uses informed consent, an ethics pre-check and its own data management plan.

Retention and legal basis are proposals awaiting the university's data protection officer, and the risk assessment awaits the occupational safety organisation. Both are listed as open.

AI assistants were used throughout. The rules that kept the numbers honest were the same ones we would want from a human colleague.

AI assistance, openly

Much of V5's software, the analysis scripts, the study write-ups and this record were written with AI assistants: several general-purpose language models, from more than one provider, used as coding, analysis and writing tools alongside the project team. The automated judge in chapter 03 is a separate matter: one named model, used only to score answers, and documented there. AI use is stated plainly because it bears on how the work should be read. An assistant is fast, tireless and often right; it is also fluent when it is wrong, which is exactly the failure this book warns about. The working rules that follow exist because of that.

• Every citation and every gap claim is checked against the original paper, not taken from an assistant's summary. Some were wrong on first draft: a citation pointing to the wrong authors, and two different papers merged into one.
• Every number in the result tables is recomputed from the raw data by one script, and a second script compares every table cell in the drafts with the recomputed value before anything is published.
• Human ratings are never changed after seeing the judge. Disagreement is resolved by adding raters, not by adjusting the ones you have.
• Null and single-model results are not stretched. The quantization threshold in chapter 04 is claimed for one model family, because that is what was tested.
• Five-minute smoke tests before long runs, and the raw output read by a person.

The open use of AI is also part of what the project is meant to teach. Students will work with these tools whatever the curriculum says, and the useful lesson is not whether to use them but how. Hynebot is meant to show it in practice: a language model working side by side with the people on the project, writing code, running analyses and drafting text far faster than they could alone, while the decisions stay with people. The model proposes; a person chooses the robot's purpose, sets the protocol, reads the raw output and signs off every number. The same holds for what is learned. A model can produce working code for a motor controller, but understanding why the controller turned out to be a positioning drive, or why a fluent answer can be wrong, is what a student takes away from the project, and that cannot be handed over.

Why the results are published here

The measurement campaign was written up as four studies, and their content is in this book:

Two of the four have complete data; the other two are incomplete. Retrieval over scale has a mechanism, a cross-language probe and a smoke test, but no measured retrieval precision. Where the pipeline breaks has three documented failure modes, but no rates: how often a misheard word reaches the final answer, or what share of wrong answers each stage causes. Both are incomplete for the same reason: the data they need comes from the robot in use, through its interaction log, and the robot is not yet in use.

We have chosen to publish the results here, openly and with their sources, rather than take them through journal peer review first. That is not a judgement on peer review, which this work would benefit from and may still get. It is a question of what the studies were for. They were not research for its own sake. They were the groundwork a physical robot needed before it could be built: which model, at what compression, with what retrieval, on what hardware. Those answers were needed within weeks, by the people building V5, and they are needed this year by the next team, by other workshops building robots with students, and by the companies around JHC deciding what to build. A public, versioned record lets the work be corrected and iterated as freely and as quickly as the robot itself.

For groundwork of this kind the review that matters most is the machine. If the robot built on these findings answers correctly, in Finnish, at the printer, within the time a person is willing to wait, then the theory and the plans were right. If it does not, the record shows exactly which number to go back to. The cost is that nobody outside the project has yet checked these results formally. We have tried to compensate by publishing what a reviewer would ask for: the question design, the judge prompt verbatim, the rater agreement with its weaknesses, question-level statistics rather than inflated sample sizes, the runs that went wrong, and the limits below. The questions, raw answers, scores and analysis scripts are available from the J. Hyneman Center on request.

Limits of the language-model results

• One set of 40 questions, written by one domain expert and not piloted.
• One automated judge, from a single model family, checked against three human raters on 60 answers.
• Sampling at temperature 0.7 only; no greedy-decoding control.
• One hardware platform and one runtime; latencies are specific to both.
• The quantization threshold shown for one 70B model at Q3 and Q4.
• The retrieval comparison is twelve answers about one printer.
• Measured parts of a system, not a system in use.

The biggest unknown is not technical. Nobody who did not build V5 has used it yet.

The plan is a set of layers, each of which has to be usable on its own before the next is added. The brain and the body are separate layers, which is what lets the brain be finished on a desk while the body waits for parts. STATPS

Layer 5 opens only when layers 1 to 4 work and the interaction logs show that people actually need the robot to go somewhere on its own. Until then it stays closed, deliberately.

The questions we would answer first if we started again. None of them names a part.

• Which purpose leads: presence, assistance or demonstration? Written down, with the test that tells you it works.
• What is the smallest version that someone outside the team would use every week? Build that first.
• How many actuators does the motion you need actually require? Count the motors before choosing the drive.
• Can every structural part be bought locally and repaired by the next student?
• Does one motor turn from your own computer, the way the robot will drive it, before the frame is drawn?
• What stops the wheels when the network drops, and how fast?
• Is the emergency stop wired in hardware, through everything that moves or heats?
• Where do the battery, the computer and the distance sensor go, before anything else is placed?
• Which languages must it speak? Test every model and compression level in those languages, not in English.
• Is the evaluation protocol fixed before you look at any answers, with repetitions and a scorer you have checked against people?
• Do answers about a specific machine come from that machine's documentation, with the source shown?
• What does the microphone keep, and who can see it?
• Is autonomy behind a gate that real use has to open?
• Which subsystem got the hours last month, and is that the one that leads?

Where the project's own sources disagree, or a decision is still open. Listed rather than resolved silently.

Every reference key in the text points to an entry in this list, grouped by kind of evidence. Paths refer to the project archive: “V1–V4” is the folder 06 Hynebot, “V5” is 07 Hynebot V5.