I am an Assistant Professor in Autonomous Systems at the Engineering and Technology Institute Groningen (ENTEG), University of Groningen. My work is nonlinear control and port-Hamiltonian systems, applied where machines meet the real world: monitoring the health of large structures, sorting textile waste with hyperspectral cameras, and robotic laser welding for shipbuilding.
I care about machines that are honest about their energy and their limits, and about teaching engineers to build them too. I run MCDC, a first-year course where students design, argue, build, and occasionally break things under real constraints. I also supervise PhD candidates and EngD trainees. Now and then something leaves the lab altogether. Last February it was a lion head, in a museum in Amsterdam.
I'm from Costa Rica. I live in Groningen with my family.
My current funded projects span structural health monitoring, AI-driven industrial sorting, and robotic welding for shipbuilding. I supervise a team of PhD candidates and EngD trainees across these projects.
The pod inside the goTube in Emden, 8 September 2026. Still from our video. Test infrastructure: Hochschule Emden/Leer.
The pod moved, and the tube answered.
On 8 September about eight of us drove from Groningen to Emden, to the goTube of Hochschule Emden/Leer, a steel test tube 27 metres long on the university campus [1]. We fixed sensors to its walls with magnets. Keyvan ran the measurement system. Hrishikesh swung the hammer. Zakir, a bachelor student, kept the logbook, which on a day like that is the job everybody forgets until it is missing. Then our hosts ran the pod back and forth, and every sensor listened.
This page is about why we do that, who does it, and where the work stands.
Listening to a tube
I once wrote that structural health monitoring is the discipline of listening to what a structure is trying to tell you. HyperBRIDGE is where that sentence has to work on a real object. The test track at the European Hyperloop Center in Veendam is 420 metres long and 2.5 metres across [2].
A steel tube rings when you hit it. Every structure has a handful of tones it prefers, its natural frequencies, and a shape it moves in at each one. Hit it with a hammer, put accelerometers on its shell, and you can measure both. Come back a year later and do it again. If the tones have shifted, something has changed. A bolt may have loosened, a support may have settled, a weld may have started to crack.
The difficulty is that a tube this size also hums for reasons that have nothing to do with damage. Wind. Temperature. People walking inside it. A pod going past. The work is to tell those apart, with as few sensors as possible, before anyone has to climb in with a torch.
Two test sites, one border
HyperBRIDGE is an Interreg VI A Deutschland-Nederland project. It runs from 1 October 2025 to 30 September 2029, with eligible costs of €4,828,614 [3]. The European Regional Development Fund pays €2,256,827.99 of that. Niedersachsen, the Dutch Ministry of Economic Affairs and the Province of Groningen add their own share [3].
Nine partners take part. The European Hyperloop Center leads, with the University of Groningen, Hochschule Emden/Leer, Hanze University of Applied Sciences, and the companies Omnidots, V-Tron, Quantumfrog, Concept7 and vrame Digital [3]. The idea fits in a sentence. The region has two hyperloop test sites, one on each side of the border, and the project uses them as a single place to develop and test [3], [4]. At least 20 small and medium-sized companies are meant to take part [3].
The project works on four things: monitoring the health of the infrastructure, communication between pods, an operating system for hyperloop test vehicles, and interactive digital twins [3]. Nobody involved pretends this is a train you can board next year. Hochschule Emden/Leer expects commercial hyperloop after 2030 [5]. That suits me. The interesting engineering happens before anybody sells a ticket.
Our part
Work Package 1 is called Structural Health Monitoring and Sound Emission Management. Prof. dr. Maryam Ghandchi Tehrani and I run it at the University of Groningen, together with Tom Oegema of Omnidots in Leek. Between the university and Omnidots it carries a budget of almost €1 million [6].
The plan has four steps. Put sensors on both test tracks. Use the measurements and machine learning to find what is out of the ordinary. Feed the data into a digital twin built with another work package. Then show the whole system working at a cross-border event before the project ends in 2029. Behind the vibration work sits a second question: how to damp the vibration and the noise once we know where they come from.
The budget pays for two PhD positions at the university and two Engineering Doctorate positions at Omnidots [6]. That is where the people come in.
The people
Maryam Ghandchi Tehrani, of the Dynamics and Vibration group, is the principal supervisor of both PhD candidates. I co-supervise them, and I supervise the two EngD trainees. Tom Oegema brings the view from Omnidots: what a monitoring product has to do once it leaves the lab.
Keyvan Delfarah started his PhD on 1 June 2026. He works on structural health monitoring: teaching an algorithm what a healthy tube sounds like, so it can flag one that does not. He runs our measurement system in the field. Hrishikesh Sawant started his PhD on 1 April 2026. He works on noise and vibration control, and in particular on what a moving pod does to the tube around it. He models it in COMSOL first and will check the model on a beam in the lab. Both PhDs are cotutelles with Macquarie University in Sydney. They spend about two and a half years in Groningen and the last part in Australia, co-supervised by Prof. Nazmul Huda.
Enrico Portella and Rinnert Jan Politiek started their EngD at Omnidots on 16 March 2026. Enrico works out where sensors should go: the fewest positions that still tell you the most. Rinnert Jan works on dampers and acoustic control, and on getting raw data out of Omnidots' own vibration sensors. Their story, and the photographs of Rinnert Jan with our steel tube, are told elsewhere on this site, in The EngD, told by others, based on the article by Innovatiecluster Drachten [7].
Left: Rinnert Jan Politiek with the tube section in our lab. Right: the same section with a vibration sensor on its shell. Photos: Innovatiecluster Drachten [7].
Around them sits a ring of students. Nathaniel Staal built the first COMSOL model of the tube and set up the steel section in the lab. Yassin Pointner and Zakir Currimjee printed a scaled tube, hit it, and compared what they measured with the model. This autumn Timothy Galema designs a tuned mass damper for the tube, Devrim Karababa trains a damage classifier on 3D-printed beams, and Luuk Tigelaar builds a track and a cart so a moving load can run inside the lab tube. Mahmoud Askari keeps the lab equipment running and the rest of us honest about it.
The bench
Most days the work does not happen at a test track. It happens on a table in Groningen.
There is a short section of steel tube, with rings welded to its ends, clamped to the vibration table. There are 3D-printed tubes at a smaller scale, cheap enough to print again when an idea changes. There is a hammer, a set of accelerometers, a multichannel measurement system, and Omnidots sensors that Rinnert Jan has taught to hand over their raw data. And there is a COMSOL model of each object, which only earns our trust once it agrees with the hammer.
The order matters. A beam before a tube. A small tube before a big one. A model checked on the bench before it is used on a track. It is slower, and it is the only way I know to find out which of our mistakes are ours and which belong to the structure.
Out at the tracks
The first time the whole consortium sat around one table was in January, in Emden, about 20 people from universities, institutes and companies on both sides of the border [8]. Maryam, Enrico, Rinnert Jan and I drove over together and presented what WP1 would do.
The September day in Emden was the first time we put our own sensors on a full-size tube. A month later, on 9 October, we did the same in Veendam, with students along to help. We set up inside the tube, hit it, moved the sensors, and hit it again, until the time ran out.
Tube sections at the European Hyperloop Center in Veendam. Photo: European Hyperloop Center [4].
On 26 October the consortium met again, this time at the European Hyperloop Center. In the morning other work packages showed demonstrations. In the afternoon WP1 had thirty minutes. I opened with a few of them. The PhD and EngD candidates did the rest, five minutes each, and spoke for their students too. That is how it should be.
Inside the goTube research infrastructure at Hochschule Emden/Leer. Photo: Max Simson, Hochschule Emden/Leer [5].
Where things stand
On 30 October 2026, a year into a four-year project, this is the honest picture.
The first milestone asked for sensors at both test sites by the end of September. They went on in Emden on 8 September and in Veendam on 9 October. Those were measurement campaigns, not yet the permanent sensor network the project will need. That comes later.
The second step, finding anomalies with machine learning, has started early, on purpose on simple objects: a beam whose behaviour we can predict, before a tube we cannot. Hrishikesh's beam with a moving mass should be ready in the workshop by the end of November. We are also building a way to measure how hard the hammer hits, because without that number a measurement tells you only half of what it could. The next campaign in Emden is planned for the end of November or the first week of December. Nazmul Huda visits Groningen next week.
Each of our four candidates now also keeps a direct line to one other work package: pod-to-pod communication, the digital twin, the serious game, and communication with the outside world. Most of what happens in a nine-partner project never reaches your own meeting room unless somebody goes and gets it.
What I take from it
A year in, the thing I notice most is how much of this work is logistics. Vans, magnets, extension cords, weather covers, a hammer that has to arrive on time. None of it appears in a paper. All of it decides whether there will be a paper.
The other thing is the tube itself. It is patient. It rings the same way every time you hit it in the same place, which is exactly what makes it possible to notice the day it does not.
If you work on a tunnel, a bridge, a pipeline or a wind turbine and this sounds familiar, the methods travel. Write to me.
Photographs European Hyperloop Center (Veendam). Max Simson, Hochschule Emden/Leer (goTube). Innovatiecluster Drachten (lab). HyperBRIDGE WP1 team (moving pod). Each caption names its source.
Funding
HyperBRIDGE (project 11186) is carried out within the Interreg VI programme Deutschland-Nederland with support from the European Union through the European Regional Development Fund. Niedersachsen, the Dutch Ministry of Economic Affairs and the Province of Groningen co-fund the project [3], [9].
Ondersteund door het Interreg VI programma Deutschland-Nederland. Unterstützt durch das Interreg VI-Programm Deutschland-Nederland.
References
Numbered in order of first appearance, in IEEE style. All links accessed 30 October 2026.
SORTED, Assen and Groningen, October 2025 to October 2026
The Textile Analyser, one of the SORTED prototypes in Sympany's innovation area in Assen. Photo: SORTED [1].
This morning we hung three posters on a long white wall in Assen, a few metres from the machines they describe. The wall had just been painted. The occasion was the SORTED prototype event at Sympany, followed in the afternoon by an open day for anyone curious about what happens to the clothes they throw away [2].
People followed the posters from top to bottom, as a story rather than a set of figures. Then they asked questions, and nearly all of them fell into three kinds. What does the AI actually decide? Why does a sorting line need robots? And what is a university doing in a sorting hall?
This page is my attempt at a longer answer to all three.
A mountain of clothes
In the Northern Netherlands about 31 million kilos of clothing are thrown away every year, and less than half of it ends up in a textile container [3]. What does reach a container goes to collectors like Sympany, which sorts some 18 million kilos a year [2]. People do that sorting by hand. Trucks arrive every day, and Sympany expects the number to grow to twenty-five a day or more [4].
Sorting by eye works well for one question: can someone wear this again? It fails at the next one. Recycling needs to know what a garment is made of, and the eye cannot tell. A cotton shirt and a shirt of cotton and polyester look the same on the table. A few percent of elastane in a blend is enough to cause trouble further down the recycling chain [4].
The difference is there, but in light we cannot see. Each fibre absorbs infrared light in its own pattern. A hyperspectral camera records that pattern pixel by pixel, and a model has to read the molecules from it [4]. On a working line it has about one second per garment to do so [4].
Discarded textiles, the raw material of the whole project. Photo: Bicanski, Pixnio, as used in [4].
A year ago, in the same town
Almost exactly a year ago, on 31 October 2025, provincial and municipal representatives handed over the SORTED grant in Assen [5]. The money comes from the Northern Netherlands Alliance (SNN) through the European Just Transition Fund: €14.9 million, including €6 million of co-financing from the Ministry of Economic Affairs [5], [6]. Sympany leads a consortium of fourteen partners [5], [6]. The project website now lists fifteen [7].
Left: council member Rink of Emmen, Charles Graft of Sympany, and provincial deputies Bennema and Meeuwissen at the grant handover in Assen, 31 October 2025. Photo: Demcon industrial systems [5]. Right: a large part of the project team. Photo: Kim Stellingwerf [6].
The work is split into five packages that cover the whole chain, from collection and sorting to recycling, new business models and consumer behaviour [6]. The University of Groningen works in three of them. Gert-Jan Euverink's group works on chemical recycling of cotton and polyester, and Marijke Leliveld's on how people buy and discard clothes [6]. Our part is the sorting.
So when visitors asked what the university was doing there, the question was understandable. On the project website the university is listed for research on behaviour and system change [7]. That is true. It is also half the story.
Teaching a line to see
Sympany, Demcon and Code for Good have already built three of the seven modules of the future line: a singulator that separates single items from the incoming flow, a bag opener, and the Textile Analyser, which looks at each garment with cameras, sensors and AI [1]. Code for Good builds the models that judge whether an item can be worn again, trained on images that operators capture on the floor [8].
Our task is the robotic sorting cell: identifying textiles down to the fibre, and handling them with robots [9]. Two PhD candidates and two EngD trainees work on it, backed by an investment in robots and sensors [9]. The idea is that the cell becomes a shared platform for the consortium, the place where results from the lab meet a real sorting line [9].
In practice that means two questions, and they map onto the posters. How does a robot pick a crumpled garment out of a pile and lay it flat on a belt? And once it lies there, what is it made of?
Neither has a clean answer yet. A garment has no fixed shape. It folds, tangles and hides its own corners. Blends blur the spectra. So we start simple and build up: towels before shirts, one sensor before many. For identification the plan is sensor fusion, combining hyperspectral images with microscopy and other measurements, so that when one sensor is unsure another can still speak [4].
The people
Testing how robots should grasp textiles: a robot arm and the humanoid hold the same shirt. From left: Sepide Taleb, me, Ali Ahmadi, Azamat Kaibaldiyev and Ammar Akhlaq Ahmed. Photo: Willem Serné, AV-Services, University of Groningen [4].
Ali Ahmadi joined as a PhD candidate in February 2026. He works on the robot's side of the problem: seeing a garment with a depth camera and deciding where to grasp it. He is building his own collection of garment images, because the one he needs does not exist yet.
Azamat Kaibaldiyev started the same month. He works on identification: reading fibre composition from hyperspectral images, and adding sensors that look at the fibres themselves. Under a microscope polyester runs in straight lines, cotton in less straight ones, and wool is a mess [4].
Rick Drenth began his EngD on 1 September. His job is to turn lab results into a cell that could run in industry. He is drawing its layout and modelling it in simulation, two robot arms, a gantry and a conveyor, so we can rehearse the choreography before the hardware arrives.
Kavian Soukhaklari began his EngD on 1 October. He works on identification too, with an eye on what it takes to run AI models on a production line rather than on a laptop. Both trainees follow the Engineering Doctorate in Autonomous Systems, which I wrote about in The EngD, told by others.
Michele Cucuzzella is first supervisor of Ali, Azamat and Rick, and LiangLiang Cheng of Kavian. I co-supervise all four. Nabeel Younas and Alexander Hübl complete the staff team [4]. Students carry real parts of the work. Merijn Molenaar is building the microscopy line with Azamat. Can Habib Varon is teaching a robot to pull a garment out of a bin. Michal Dziubany and Ammar Akhlaq Ahmed work on the humanoid's hands.
Left: one shirt, two robots, one shoulder each. Right: the gripper's two fingers on the fabric. The whole problem lives in that pinch. Photos: Willem Serné, AV-Services, University of Groningen [4].
Where things stand
Industrial robot arms are on order. Until they arrive we practise with a small collaborative arm and a humanoid, on towels first [4] and then on shirts like the red one in the photos. A towel is a forgiving garment: flat, square, and always the same. It is the right place to fail cheaply.
The partners' prototypes show that the line can be automated [1]. The next phase joins the remaining modules into one industrial line, tested in Sympany's sorting hall in Assen [1]. Our cell has to fit into that line, and its sensors have to keep pace with it.
On identification, three measurement lines now run side by side: microscopy, Raman spectroscopy, and infrared at longer wavelengths. None of them replaces the hyperspectral camera. Each should make it harder to fool.
What I take from today
The questions in Assen were good ones, and none of them had a short answer. What does the AI decide? For now, mostly what a garment is made of. Whether someone will wear it again is harder. Why robots? Because no one can lay out a garment every second, all shift, every day of the year. Why a university? Because handling a crumpled shirt reliably is still an open problem, and open problems are what research is for.
Last month I told a journalist that we should not underestimate what people can do [4]. I would say it again today. The line we are building has to learn from the people who sort by hand before it can take over any of their work.
Funded by Samenwerkingsverband Noord-Nederland (SNN) through the European Just Transition Fund, with co-financing from the Ministry of Economic Affairs
Photographs Willem Serné, AV-Services, University of Groningen (lab, 2 September 2026). Kim Stellingwerf (project team). Demcon industrial systems (grant handover). SORTED (Textile Analyser). Bicanski, Pixnio (textiles). Each caption names its source.
References
Numbered in order of first appearance, in IEEE style. All links accessed 30 October 2026.
Robot welding in closed ship sections, with shipbuilders in the north of the Netherlands. In preparation, October 2026
Under the cargo hold of many ships lies a second floor. Between the outer skin and the inner bottom runs a grid of steel cells, and once the last plate goes on, each cell is a closed box. The way in is a hole cut through a wall. In one study of double-hull ships, the welding robot had to fit through an access hole 600 millimetres wide and 800 high [1]. A welder goes through holes like that on hands and knees, pulls a torch and its cables in after them, and welds the seams of the cell. Then the next cell. Then the next.
RoLinGS is about putting a robot in that box instead. The name comes from the Dutch Robotlasprocessen in Gesloten Scheepssecties: robot welding processes in closed ship sections. We are preparing it with shipbuilding partners in the north of the Netherlands.
This page says what the problem is, what we at the University of Groningen want to bring to it, and where things stand. It will say more once there is more to say.
A box you cannot see into
Many welding robots in shipyards work from above, hanging from a gantry over a block that is still open. That works until the block is closed. After that, anything that welds inside has to come in through the same hole as the welder and carry itself from cell to cell.
Getting in is only the first problem. Steel moves when you weld it. The metal heats up, cools down and shrinks, and a plate that was flat can pull out of shape. Real parts never match the drawing exactly, either. Gaps open and close along a seam, and a frame sits a few millimetres from where the model puts it. A welder sees this and adjusts without thinking. A robot has to find the seam, follow it and notice when the gap changes. Teaching machines to see a seam is a research field of its own, and a recent review names depth perception as one of its bottlenecks [2].
Why shipbuilders want it
The short answer is people. At the end of 2024, the Dutch employee insurance agency UWV rated the labour market for welders and sheet-metal workers as zeer krap, very tight [3]. The pressure is not only Dutch. Korean shipbuilders turned to welding robots because skilled welders had become hard to recruit, at home and abroad [4].
The longer answer is the work itself. Hours on your knees in a closed steel box, with heat, fumes and noise, are hard on a body. If a robot takes the seams inside the box, the welder can move to work that needs a person.
Where control theory meets the shop floor
My background is control: models, stability, proofs that a system will do what you ask of it. That world is clean. A shipyard is not. A robot in a closed section works from a 3D model that never quite matches the steel in front of it. Its sensors see only part of the cell, and its cables can snag on a frame.
That gap is what interests me. Our part at Groningen is the robot's side of the problem: how it plans its motions from the model, how it uses what its sensors report to correct that plan, and how we can say, with some rigour, that it will behave when the steel does not match the drawing. Formal methods earn their place here only if they survive the shop floor. RoLinGS is where we find out.
The people
At the University of Groningen I work on RoLinGS with Bayu Jayawardhana, professor of mechatronics and control of nonlinear systems and scientific director of the Engineering and Technology Institute Groningen (ENTEG). Together we shape the university's part of the project.
The partners are shipyards and training and knowledge institutions in the north of the Netherlands. I will name them here once the project has started and they have agreed to it.
Where things stand
As of 30 October 2026, RoLinGS has not started. We are still preparing it with the partners. There is no robot in our lab, no test piece and no result to show.
What we have done is the groundwork: meeting the partners, learning how a closed section is built, and working out where a university fits in a project that has to end on a shipyard floor. When the work starts, this page will follow it.
DTPA lab, University of Groningen, since June 2026
The robot came on a Monday. At four in the afternoon on 1 June 2026, the supplier, SmartRobot.Solutions, brought it to the DTPA lab at Nijenborgh 4, helped us take it out of its box and spent the next hour teaching us how to run it safely. Our lab manager led the setup. A few students stayed for the whole session, which was the point.
It had been a year in coming. We first met as a team in May 2025 to agree how we would share the robot, long before there was anything to share. The minutes of that meeting are mostly about emergency stops and network isolation. In hindsight that was the right order.
What it is
The Unitree G1 is a humanoid 1.32 metres tall that weighs about 35 kilograms with its battery [1]. The research version has between 23 and 43 joints, depending on how it is configured: six in each leg, up to three at the waist, five in each arm, and optional joints in the wrists and hands. The optional hand has three fingers and seven joints between them [1]. The robot carries a depth camera and a 3D LiDAR, and a battery lasts about two hours [1].
Those are the manufacturer's numbers. In practice the robot spends far more of its life in simulation than on its feet, and that is deliberate.
It is not a toy and we do not treat it as one. Nobody stands within two metres of it while it runs. Every new experiment is announced first. Nobody changes its main program without telling the lab, because the same robot also gives demonstrations, and a demonstration is a bad moment to discover that someone has changed how it walks.
One set of laws, two machines
The question I care about is narrower than what a humanoid can do. It is this: can one family of energy-based control laws serve machines as different as a humanoid hand and an industrial robot arm?
I have written elsewhere about what I think about when I think about port-Hamiltonian systems. The short version: you write the robot down as an account of energy. Where it enters, where it leaves, what it does in between. The ports are where the robot touches the world [2]. A controller, seen this way, reshapes the energy landscape so that its lowest point sits where you want the robot to be, and it keeps track of every bit of energy it adds or takes away [3].
Control as reshaping energy. Move the lowest point, and the joint goes there. Graphic: Mauricio Muñoz-Arias.
None of this is new to me. During my PhD I wrote a grasping strategy on these principles [4]. More recently, with colleagues, I published a force and impedance controller for an industrial arm built the same way [5]. The G1 is the stress test. A humanoid has more joints, less patience and a floor to fall onto. If the structure holds there, it holds.
The fingers first
The first serious attempt came from an MSc student in Systems and Control, who graduated in September. The project built an energy-based controller for the twelve finger and thumb joints of the G1, starting from the robot's own model.
It has two modes. In free space each finger behaves as if a virtual spring pulls it towards its target. Once the hand touches something, the controller stops chasing a position and holds a chosen force instead.
The two modes of the finger controller. Graphic: Mauricio Muñoz-Arias.
In simulation it closed cleanly on objects of different widths. On the real robot it ran, which is not the same thing. The hand accepts position commands, not torques, so a law that speaks in forces has to be translated before the hand will listen. The project built that translation. It works, within limits we can name, and naming them was half the work.
The G1 reaches out to shake a hand. Video: Ammar Akhlaq Ahmed.
That is the part I like most. A controller that only works in simulation is a hypothesis. Hardware is where it becomes a result, or does not.
Walking, slowly
An MSc student in mechanical engineering is working on locomotion from first principles. As of this week a static gait walks in MuJoCo [6]: a PD controller with gravity compensation, balanced at every instant. Static means the centre of mass never leaves the area over the feet. It is slow, and it is honest.
A static gait, seen from above. The dot is the centre of mass; the shaded area is what the feet cover. Graphic: Mauricio Muñoz-Arias.
My first question at the last meeting was whether gravity was switched on in the simulation. Every simulation deserves that question, and it is cheaper to ask it early.
Next come dynamic walking, then push recovery, then a check of how sensitive all of it is to a model that is slightly wrong. Then Isaac Sim [7]. Then, from January, the real robot. Not before. Walking on the physical G1 under our own controller is a plan for January, and this page will say so until it is not.
Most walking controllers in the literature solve an optimisation problem at every step and keep a PD loop as the lowest layer. We are starting from that lowest layer and working up. It is the slow way. It is also the way in which you understand each layer before you add the next.
The rest of the team
Around that core sit four other projects.
An MSc student in artificial intelligence is studying mixture-of-experts locomotion: several small walking policies, each good on one kind of ground, and a mechanism that chooses between them. Until January the work is reading and replicating. The original contribution starts after that.
A second MSc student in artificial intelligence starts in November on reinforcement learning for walking, grasping and placing. How the learning projects fit with the model-based one is still open. The agreement so far is that they should complement each other, not compete.
A BSc student is working with vision-language-action models: a simulated G1 that should spot a faulty product on a workbench and move it to a bin. A first demo walks a pretrained G1 up to the product in simulation. The project ends in February.
An MSc student works on grasping, in simulation for now. And before all of them, a bachelor student in Industrial Engineering and Management got a simulated G1 to walk to an apple, pick it up and put it on a plate, then wrote a thesis about why that is harder than it sounds. That student graduated in July.
Thursdays at eleven
Every other Thursday at eleven we meet in the DTPA lab, room 5112.0073. Each student brings two or three slides: what moved, what is stuck, what help is needed. Five to seven minutes each. The rule exists because otherwise the most exciting project takes the whole hour.
The meetings are mainly for the students, but the rest of the group is welcome, and they come. At least six teams now want time on this one robot. A second robot would help. The minutes call that wishful thinking, and the minutes are right.
Not every problem is robotics. The screen in the room still refuses to talk to the conference system. The current theory is a USB-C cable.
Where things stand
On 30 October 2026, this is the honest state of things.
An energy-based finger controller has run on the real hand. A static gait walks in simulation. A learning-based demo walks a simulated robot up to a workbench. The real robot walks, but on the manufacturer's own controller; walking on ours is January's job. The hands still accept positions rather than torques, which keeps the energy-based story one translation away from the hardware.
The G1 walking on the manufacturer's own controller while three rovers keep formation around it. Video: Ammar Akhlaq Ahmed and Ridho Rosa.
The next meeting is on 12 November.
What I take from it so far
Five months in, the robot is not the hard part. What I did not expect is how much of the work is deciding what not to do yet. No walking on hardware until the simulation earns it. No learning on top until there is a model-based baseline to compare it with. No letting six teams onto one robot without a calendar.
The energy accounting has to be exact. So, it turns out, does the schedule.
[4]M. Muñoz-Arias, J. M. A. Scherpen, and A. Macchelli, “An impedance grasping strategy,” in Proc. 53rd IEEE Conference on Decision and Control, Los Angeles, 2014, pp. 1403–1408.
[6]E. Todorov, T. Erez, and Y. Tassa, “MuJoCo: A physics engine for model-based control,” in Proc. IEEE/RSJ International Conference on Intelligent Robots and Systems, Vilamoura, 2012, pp. 5026–5033.
I hold an education-focused profile (60/40 split) at ENTEG. My teaching spans undergraduate craftsmanship, EngD professional development, and PhD supervision. I completed my Senior Teaching Qualification (STQ) in 2026.
MCDC
IEM bachelor, University of Groningen, 2023 to 2026
The first MCDC symposium, April 2023, seen from the balcony. Photo: MCDC archive.
At half past twelve on symposium day the atrium is nearly empty. By one o'clock it is full of machines.
They come in carrying them. Grippers in shoeboxes, rovers under one arm, robot arms wrapped in a jacket so the cables do not snag. A laptop, a battery, a bag of spare screws, a poster still warm from the printer. Somebody is reprinting a bracket that cracked on the bike ride over. Somebody else has just found out that the thing that worked at midnight does not work in daylight.
Then the jury starts walking, and for an hour third-year students explain to strangers why their design looks the way it does. Ten weeks earlier most of them had never put a part on a print bed. That hour is what the course is for. Everything before it is how we get there.
Symposium 2026. A small red parcel from a Groningen bookshop, kept behind someone's back. Photo: MCDC archive.
Two courses, one cohort
MCDC is not one course. It is two course units of 5 ECTS each, Mechanical Craftsmanship [1] and Design and Construction for IEM [2], which third-year students in Industrial Engineering and Management take in the same block, from February to April, in the same teams. Mehran Mohebbi coordinates Design and Construction. I coordinate Mechanical Craftsmanship.
One is the thinking half. In DC the students follow the systematic design method of Pahl and Beitz [3]: requirements, function structures, a House of Quality, failure modes, hand calculations, finite elements. Their designs stay on paper and in CAD.
The other is the making half. In MC the same students take a design into plastic and servos, and then they live with whatever does not fit.
I wrote a short note once, On teaching SolidWorks when SolidWorks is not the point. Its last line still holds. The software is a pencil. The constraint is the point. That note was about the first three weeks. This page is about the rest.
Four years, four machines
The course code never changed. The object on the table changed every year.
2023, grippers. Nineteen teams, nineteen robotic grippers, designed in SolidWorks and printed in PLA. It was the first edition and it was simple on purpose: one team, one object, one symposium. Everything since is a variation on that afternoon.
A gripper set up to sort cutlery, with the labels written by hand that morning, April 2023. Photo: MCDC archive.
2024, a rover that runs on air. Teams now worked in triads: three teams, one machine, each team building a different part of it. The rovers were driven by compressed-air engines, and the air rode on board in refitted fire-extinguisher bottles, filled at a ten-bar station. It was the first year the hard problem was not inside a part but between teams. Eleven rovers rolled into the atrium. One of them met every requirement in the challenge. One.
Two compressed-air rovers, two bottles each, with springs and dampers on every wheel, April 2024. Photo: MCDC archive.
Left: one bottle, three wheels, a microcontroller taped to the tank. Right: a chassis printed as an open truss to save plastic. Photos: MCDC archive.
That rover also became a research project. Max Kloosterman, who took the course and then taught in it, turned a modular pneumatic rover into a platform for teaching control, and the three of us presented it in Salamanca in 2025 [4].
2025, an arm that has to mount on anything. Each triad built one robot arm meant to sit on a rover or a drone. One team owned the mounting and the yaw joint, one the pitch joint and a linear extension, one the wheel and propeller at the end. The whole arm had to come out of one print bed, 256 millimetres on a side, with no more than one kilogram of plastic and no more than twenty-four hours of print time.
Left: an arm taken apart, down to the printed screws. Right: a wheel with its own internal ring gear and a bearing pressed into the hub. Photos: Miguel Ruiz.
One kilogram sounds like plenty until a team weighs its first prototype. Every gram on the end of an arm is a gram the shoulder has to lift. Students who started the block asking how to make something work ended it asking how to make it lighter. Nobody lectured them into that question. The scale did.
Mounting, extension and wheel in one arm, clamped to the table with two bar clamps, April 2025. Photo: Miguel Ruiz.
2026, an arm and a hand. We split the robot in two. One team built the arm, another built the hand, and the two had to meet at a quick-attach interface that changes tools in under thirty seconds. Each pair worked for one domain: food, agriculture, textiles, assembly or the laboratory.
Halfway through, we changed a rule. Until then every arm sat on a fixed printed block. On 25 February 2026 we removed it. From that day each team designed its own base: no heavier than 150 grams, no more than four hours to print, clamped to a desk with two bar clamps, with a quick-mount for the arm, and kept outside the one-kilogram budget. Changing a requirement in week three is unfair in the way real projects are unfair. It also produced the best mounting designs we have seen.
Printed gear and belt drives with their assembly guides, April 2026. Photo: MCDC archive.
Ten weeks
The rhythm has settled. In week zero a survey sorts students into teams by skills and schedules. In week one they assemble a small two-joint manipulator from a kit, so that everyone has held a servo before anyone designs around one. Weeks two and three are the first design cycle, and the first argument with the other team about where the interface goes.
Week four is the individual exam. Each student, alone, with a laptop and a clock, turns a set of drawings into a printable part. You cannot pass the course without passing it. It is the only moment in the block when nobody else on the team can carry you.
Weeks five and six are fabrication and the midterm presentation. Weeks seven and eight are the second cycle, and in DC an individual oral exam. Week nine is integration, which is a polite word for discovering what the other team assumed. Week ten is the symposium.
Why the teams got smaller
The triads taught us something we had not planned to teach. Most of engineering is the interface between people. Each triad had an integrator, a student whose job was to keep three teams talking, and some of them did that job better than most project managers I have met.
They also taught us that a triad is too big for ten weeks. Too much time went into meetings and not enough into parts. In 2026 we moved to pairs of teams. The interface stayed, and so did the arguments about it. There were simply fewer people to have them with.
Talking to a microphone
Every week each student records a short audio journal. Not a written report: a few minutes of speaking, in answer to a prompt. Speaking is harder to polish than writing, and that is why we chose it.
The journals are read by people who do not grade. They look for moments when a student notices how they are thinking and then does something about it. An anonymous summary comes back to the teaching team each week, and the next prompt changes in response. The prompts lean on two ideas from cognitive science and motivation research: relevance realization [5] and self-determination theory [6]. Martijn van der Steen helped start the practice, and Ana Lazăr wrote and refined most of the prompts. Across two cohorts we collected close to a thousand recordings.
The phrase I hear most often at the symposium is a version of the same sentence. For the first time, a student says, I feel like an engineer. They are usually a little surprised to hear themselves say it.
In numbers
Over four editions, 287 students sat the Mechanical Craftsmanship assessment and 278 passed. The yearly pass rate has stayed between 93 and 100 percent while the machine on the table got harder every year.
We have also tried to give back what we learned. We presented the hands-on design of the course at the university's Education Festival in 2024 [7], the reflective journals at the same festival in 2025 [8], and team-based learning at EuroSoTL in Groningen in 2025 [9].
Utrecht
In the autumn of 2025 the University of Groningen nominated MCDC for the Dutch Education Award 2026, the national prize for educational innovation in vocational and higher education [10]. Each university may put forward one team a year [11]. Our nomination was called Design and Craftsmanship in Concert: Building Professional Identity Through Experiential Learning.
In April a small group of us took the train to Utrecht for the jury interview. The day before, colleagues gave up a Monday morning to play a hostile jury so that the real one would feel gentle. It did not, entirely. In June the awards went to three university teams [10], and we were not one of them.
I do not count that as a loss. Writing the nomination forced us to put four years of changes into one argument, and to check that the argument was true. Some parts were stronger than we thought. Some were weaker, and we have been fixing those since.
This autumn
The next symposium is in April 2027. The challenge is written, and right now it is being broken on purpose.
Every Wednesday afternoon since September, six new teaching assistants have met at the BorghLab to play the students. They read the challenge document cold, print parts, miss deadlines, argue about interfaces and present to a rubric, so that every unclear sentence and impossible requirement turns up now instead of in February. Luis Esquivel-Sancho plays the teacher. Robin Keekstra, back for another year, coordinates the assistants. Mehran and I sit at the back and take notes.
It is the same lesson the students get, one step removed. You do not know if a design works until someone who did not write it tries to build it.
[8]M. Mohebbi, A. Lazăr, M. van der Steen, M. Muñoz-Arias, and M. Lazăr, “Rethinking education with relevance realization,” presented at the RUG Education Festival, Groningen, Mar. 24, 2025.
Short writing. Things I notice, things I think about, things I cannot fit anywhere else.
On teaching SolidWorks when SolidWorks is not the point
Every year I watch students spend the first three weeks of MCDC trying to learn the software. They want to get the tool right before they get the thinking right. I understand the instinct — it feels safe. But SolidWorks is not the point. The constraint is the point. The 1 kg limit is the point. The dyad is the point.
The software is just a pencil.
When I tell students this, some of them look relieved. Others look more anxious. The ones who look more anxious are usually the ones who will learn the most.
Why I built a lion head animatronic for a museum
A few years ago I decided to build a lion head animatronic using a Raspberry Pi 5, a Hailo-8L neural processing chip, and Dynamixel servos. It now lives at the Wereldmuseum Amsterdam. The full story is here.
The honest answer to why: I wanted to prove to myself that I could still build something with my hands. Research can become very abstract very quickly. You write papers, you review papers, you give talks about papers. The lion was a correction.
The other honest answer: Hugo thought it was the best thing I had ever done.
Groningen in February
There is a particular quality of light in Groningen in February. It is not the dark of December — that is total and complete. February is something else: grey light that seems to arrive from no direction, a sky that refuses to commit. You learn to find warmth in small things. The fietspad is empty. The canal is still.
I have been here long enough that this feels like home. I am still surprised by this fact.
Corto Maltese and the ethics of wandering
Hugo Pratt understood something about freedom that most adventure stories get wrong. Corto Maltese is not free because he has no obligations. He is free because he chooses his obligations carefully, and he is honest about the ones he cannot escape.
I read Corto Maltese in Spanish, which is probably the correct language for a character who is always slightly out of place wherever he goes.
The hyperloop is just a train that hasn't been humbled yet
Every new transportation technology goes through the same arc. First: boundless optimism, physics-defying projections, magazine covers. Then: the boring problem of making it actually work at scale, in weather, with real maintenance budgets.
Our job in HyperBRIDGE is structural health monitoring — which is, fundamentally, the engineering discipline of listening to what the structure is trying to tell you. Structures always have opinions. The interesting question is whether you have the instruments to hear them.
Chess and the illusion of control
I play chess badly. I play it often. These two facts are related.
The thing that keeps pulling me back is the clean relationship between decision and consequence. Every bad move is immediately punishable. There is nowhere to hide. I find this clarifying, even when it is humiliating.
Port-Hamiltonian systems have a similar quality. The energy accounting is exact. If something goes wrong, you can trace it.
What I think about when I think about port-Hamiltonian systems
I think about energy. Not in a mystical way — in a very specific, accountable way. Where does the energy enter the system? Where does it leave? What does it do while it is inside?
A port-Hamiltonian model is a way of writing down a system so that these questions have clear answers. The ports are where the system touches the world. The Hamiltonian is what the system is carrying. The structure matrix is the grammar of how energy moves.
When you design a controller, you are essentially reshaping the energy landscape. You are telling the system: here is where I want the minimum to be. The system will find it.
Hugo at five: what he is learning that I am not
Hugo asks why about everything. Not the polite, conversational why — the persistent, recursive, genuinely-wants-to-know why. I have noticed that I stopped asking why somewhere along the way. I started asking how. How does this work. How do I fix this. How do I model this.
Why is harder. Why requires that you be uncertain about the goal, not just the method.
I am trying to learn it back from him.
Outreach
Work that left the lab. Demonstrations, installations, exhibitions, and the occasional attempt to explain autonomous systems to people who did not come here to hear about autonomous systems.
Engineering that only ever exists on a bench is hard to argue with and hard to learn from. Putting something in front of an audience that has no obligation to be impressed is a different kind of test, and usually a more honest one.
An autonomous animatronic lion head, installed for the spring holiday week alongside Chinese lion dance workshops. It read visitors' movements with a pose model running on a neural chip and answered with its eyes, ears and mouth. Several hundred visitors, mostly children. Read the full story.
Two and a half years of the Engineering Doctorate in Autonomous Systems, as newspapers, broadcasters, a podcast, the host companies and the trainees themselves described it. Ten photographs, nineteen sources. Read the full story.
The lion head installed in the Wereldmuseum, roped off before opening.
For one week in February the lion head lived in a museum in Amsterdam, on a black table under a brick arch, and several hundred strangers walked up to it and found out that it was looking back.
It sees you through a camera. It reads your body with a pose model running on a neural chip. Raise both arms and it opens its eyes and its mouth. Raise one, and it closes that eye. It winks. Kick, and its ears swing forward. Bow to it, and it bows back.
The head existed for a year before any of this. It was a student project first, then a stubborn one. Ivar Hesse worked on it and delivered a report in July 2025 whose final suggestion was, in effect: stop building this in a room and take it somewhere. That turned out to be the whole future of the thing.
So it went places. The Grote Markt in Groningen in November, in the rain, in a truck. The faculty open day in January, where the mouth had a bent piece that Robin fixed at short notice. Someone filmed that morning. That video became the thing we sent to a museum.
An introduction
Master Man Lung Tang of the Luk Hop Moon Kung Fu School in Groningen has been part of this from the start. He lent us one of his lion heads, which is not a small thing to lend. In January he mentioned he would be performing a lion dance at the Wereldmuseum in Amsterdam in February, and he passed me a contact: Carmen Abels, who runs the public programme there.
We wrote to her on 30 January, the same day as the open day demo.
“Super active, enthusiastic and wild”
Her reply, ten days later, is the best email of the whole project. It opened warmly, then said no. A temporary exhibition was not possible on that notice.
And then it offered something better: the Voorjaarsvakantie, the spring holiday week, during which Man Lung would be giving lion dance workshops. With a warning attached. Most of the visitors would be children. Children who, she wrote, can be super active, enthusiastic and wild. Was the technique strong enough for intensive use?
She added that it could be a nice test case.
We have written grant applications that asked less pointed questions. We had two weeks.
Fourteen days
What follows is what happens when a museum coordinator asks whether your prototype can survive children, and you decide the answer has to be yes.
Everything reprinted in ABS. The parts had been PLA, which is fine on a bench and brittle everywhere else. Wild children were now a design specification.
Redundancy in everything. Backup Raspberry Pis, backup mechatronics, backup cables. The whole system rebuilt so it boots and runs with nothing to configure, because on the Tuesday nobody from our side would be there and it needed to survive a day alone.
Recalibration. On 18 February all six motor ranges were measured again and widened, with a margin at each end so nothing would drive into its own limit. Several had been using only a third of the travel available to them. The difference in expressiveness was larger than expected.
Left: inside the head, a 3D-printed bracket carrying a Dynamixel servo, bolted into bamboo and gauze. Right: the Raspberry Pi 5 and Hailo-8L chip on the floor under the lion’s beard.
This is the part we like most. The frame is bamboo, lashed with cord, skinned in paper and gauze, made by hand the way it has been made for a long time. Bolted into it is a red printed bracket holding a servo. Neither one is pretending to be the other.
The brain, such as it is: a Raspberry Pi 5, a Hailo-8L accelerator running the pose model, six Dynamixel XL330 servos, one webcam. Blue tape. It ran ten hours a day for a week.
Eyes, ears and mouth. A close look at the mechanics.
Teaching it to bow
The bow was the hard one, and it is the one we care about, because bowing is not a gesture you make at a machine. It is a gesture you make at something you are treating as present.
The difficulty is that to a pose estimator a bow and a jumping jack look alarmingly similar. Both are large, fast, whole-body motions. Get it wrong and the lion solemnly bows at someone doing star jumps, which is funny exactly once.
On 21 February we captured 1,392 frames of pose data containing nine deliberate bows, and went looking for something that separated them. The feature that worked was the position of the nose relative to the shoulder line, normalised by torso length. Negative when you are upright, positive when you are folded over.
Nine bows, and the separation between standing and bowing. Optimal threshold at −0.20.
The top plot is the session itself. Nine spikes, nine bows. The lower one is why it works: standing and bowing land in largely different places, with a threshold at −0.20 between them.
The gate that made it reliable was simpler and slightly obvious in hindsight. During a jumping jack the arms go up. During a bow they stay down. Require arms down and most of the false triggers disappear. Add hysteresis, a lower threshold to leave the bow than to enter it, and it stops flickering at the boundary.
nose_below_shoulders = (nose_y - shoulder_mid_y) / torso_length
if nose_below_shoulders > -0.20 and arms_down:
is_bowing = True
if nose_below_shoulders < -0.30:
is_bowing = False
On the captured session that gives 94.5% accuracy, 86.2% precision and 93.9% recall. Not perfect. Two false positives across the run, which in a museum means the lion occasionally bows at someone who was only bending down to look at the cables. We decided we could live with that.
How to interact
This is the board that stood next to the head all week, which visitors mostly ignored in favour of experimenting.
The four interactions, from the instruction board at the museum.
Between visitors it blinks, twitches an ear, nibbles, and holds still. Stand about two metres back so your whole body is in frame. One person at a time, because it follows the first person it sees, which caused a certain amount of negotiation among siblings.
The week
The head on its plinth in an empty gallery.
Sunday 22 February. Drove down from Groningen. It was warmer than forecast so the head stayed in the car during the day and came up to the hotel at night, which is not a sentence you expect to write about a research project.
Monday 23. In at eight, installed, then a full day on the floor with visitors. Talking to the public in a museum was completely new to me. I enjoyed every minute of it.
Tuesday 24. Nobody from our side on site. The head stayed where it was and behaved.
Friday 27. Me again. I was late getting out of Groningen and wrote ahead to apologise. Fouad Riahi from the museum security team wrote back to say take it easy, we will see you when you get there. Packed everything up that evening.
Where the Lion Head lived. Lion dance workshops on the stage, the installation off to the side.Man Lung’s lion dance in the grand hall. Our head is at the right edge of the stage.
The dance is the reason any of this happened, and watching it from the balcony with our head sitting quietly at the edge of the stage was the moment the whole thing made sense. One lion carried by two people who have trained for years. One lion on a table, watching the room, doing what it could.
The grand hall during the spring holiday week.Visitors working out what it responds to.
Two lions
At some point during the week a lion dance lion, carried by two performers, came across the floor to meet the one on the table.
When two lions meet in lion dance there is a way of doing it. They approach, they look each other over, they greet. It is part of the form, not decoration. What happens in this clip is that a trained performer extends that greeting to a machine.
What we took from it
Carmen was right that it was a good test case, though not in the way we expected. Nothing broke. The ABS held, the backups stayed in their box, the plug-and-play boot worked every morning. The engineering questions all got boring answers, which is the best outcome engineering questions can have.
What was not boring was watching people decide how to treat it. Almost nobody walked up and started issuing commands. They approached it the way you approach an animal, slowly, from the front, testing.
Monday 23 February, the first day on the floor.
Man Lung says a real lion dancer tells a story through small gestures: joy, sadness, mischief. We did not build that. We built something that recognises four movements and answers with three pairs of motors. But it was enough for people to meet it halfway, and that gap, between what it actually does and what people are willing to grant it, is the interesting part.
The second National Congress on Autonomous Systems, Drachten, 2 April 2026. Sold out, about 500 people. Photo: University of Groningen, Jantina Tammes School [12].
Most of what gets written about a new programme is written by the people who run it. This page is about the rest.
Since early 2024 a regional newspaper, three broadcasters, a national financial daily, a podcast, an innovation cluster and the host companies themselves have explained the Engineering Doctorate in Autonomous Systems in their own words. Paris Avgeriou directs the programme and Laura Florez-Sampedro coordinates it. I teach in it, together with Sushant Pandey. We gathered these pieces this autumn, and they deserve a better home than an appendix.
Every claim below points to its source. Every photograph is credited to whoever took or published it.
An interview before anything existed
The first story ran before the programme did. In March 2024 the Leeuwarder Courant asked Paris what a doctorate would look like if it were carried out inside companies instead of a university lab [1]. No trainee had been hired. No company had signed. The paper printed it anyway.
By July there was a start date. The university announced two EngD programmes for September, Autonomous Systems and Sustainable Process Design, each two years long and each placing its trainees in companies in the North [2], [3]. The argument was regional from the first sentence: train engineers here, and give them a reason to stay. NOM's magazine NOMMER picked it up [4]. So did RTV Noord, RTV Drenthe and Omrop Fryslân [5].
From the university's July 2024 announcement of the two EngD programmes. Photo: Wiebren de Jong, University of Groningen [2].
Public money follows the promise
In November 2024 the regional partnership SNN listed TONIC among its showcase projects from the European Just Transition Fund. TONIC funds the programme together with Innovatiecluster Drachten. Its subsidy came to €3,972,466 [6]. In January 2025 the Province of Fryslân presented the cheque in person and named Ventura Systems in Bolsward as one of the first host companies [7].
By then the companies had stopped waiting for us to explain them. In November 2024 Philips Drachten advertised its own EngD position: a trainee to optimise the drive trains in its shavers and trimmers [8].
Drachten fills a theatre
In March 2025 the platform IO+ described the academic world as a driving force behind autonomous systems in the North, with the EngD at the centre of the story [9]. A month later, on 2 April, the first National Congress on Autonomous Systems met at De Lawei in Drachten. The CTO of Boston Dynamics gave the keynote [10]. IO+ covered the opening, where the rector named the new EngD as one of the ways the university trains engineers for this field [11].
The second edition, in April 2026, sold out. About 500 people from industry, government and research came, with keynotes from UC Berkeley and Airbus. Paris co-organised the congress and ran its science track [12].
The demo floor at the 2026 congress, seen from the balcony. Photo: University of Groningen, Jantina Tammes School [12].
The companies, in their own words
This is the part I find most persuasive, because none of it came from us.
In February 2026 Philips Drachten sent mechatronics engineer Gert Heerema to the university podcast RUG & Co, together with its trainee Jesse Roorda [13]. The episode is called "The university is indispensable for business." Heerema was plain about why Philips joined. The company had a clear need, and neither the people nor the resources to meet it.
Roorda described the problem. Philips first estimated some 80,000 possible drive-train combinations across its range. His prototype, run on a smaller set for the OneBlade line, narrowed about 4,000 options down to the two best. He was careful to call it a prototype. The next step is every product.
Ventura Systems builds door systems for buses. On the programme's website, Marcel Delorme put the case in one line: the EngD lets a company take on projects "you might not otherwise be able to prioritise" [14]. Their trainee, Niek Löke, uses language models to check the quality of more than a thousand product requirements. His similarity tool reaches 98 to 99 percent accuracy [14].
The trainees, explaining their own work
In August 2026 Innovatiecluster Drachten began a series on EngD trainees. The first was Rinnert Jan Politiek at Omnidots in Leek [15]. He reprograms vibration sensors so they can watch over hyperloop infrastructure. Before this he studied physics and philosophy, worked for the public health service during the pandemic, and took a master's in mechanical engineering. He calls the EngD "a bit like a work-study program for the university."
Left: Rinnert Jan Politiek with the hyperloop tube section in the lab. Right: the same section with a vibration sensor on its shell. Photos: Innovatiecluster Drachten [15].
The second was Damien Dufour, Lead Engineer for maritime robotics and AI at AutoMooring Solutions in Groningen [16]. He worked at the company before the EngD began and designed the first prototype of its autonomous mooring system himself. Now he builds neural networks that find mooring points from a camera at sea, where reflections, spray and changing light undo results that looked fine in the lab.
Damien Dufour (left) at the AutoMooring Solutions stand in Gorinchem, where the company placed third for the Innovation Award for the maritime industry. Photo: Innovatiecluster Drachten [16].
His advice to companies is to choose a problem that is genuinely hard. In his view a trainee is not extra engineering capacity but a new capability the whole team builds (my paraphrase of the Dutch).
Left: with the scale model of an LNG carrier used to test the mooring arm. Right: at the bench. Photos: Innovatiecluster Drachten [16].
This autumn
In August the Financieel Dagblad wrote about digital growth in the northern high-tech sector and the place of the EngD in it [17].
In October, experts from TNO, the university and regional companies met at Philips in Drachten for the third session of the Roadmap Autonomous Systems North Netherlands. The university runs the roadmap with TNO, EDIH North Netherlands and the cluster [18]. The heating failed that morning. People worked in their coats until three in the afternoon, which by all accounts kept everyone awake.
The third roadmap session at Philips, Drachten, 8 October 2026. Photos: Innovatiecluster Drachten [18].
What I take from it
A programme that lives inside companies is hard to see from outside. Our trainees work in Leek, Bolsward, Drachten and Groningen, behind other people's badges and other people's firewalls. For most of the region, the press is the only window onto what they do.
Reading it all in one sitting, what strikes me is how fast the voice changed. In 2024 the university explained the idea. By 2026 the companies and the trainees were explaining it themselves, and they did it better than we did. We paid for none of it.
The programme is also the first academic programme to come out of Campus Drachten [19]. That matters to the people who built the campus as much as to us.
If your company has a problem that is genuinely hard and nobody in-house has the time for it, the programme page has the details. Or write to me.
Sources gathered with Paris Avgeriou, scientific director of the programme
Photographs University of Groningen and the Jantina Tammes School (congress; programme launch, by Wiebren de Jong). Innovatiecluster Drachten (trainees, lab, roadmap session). Each caption names its source.
References
Numbered in order of first appearance, in IEEE style. All links accessed 29 October 2026.
On problems, objectives, and the two steps that stand between them.
Notes towards a short book on research and design methodology, written for engineers. Three chapters so far, twenty-four diagrams, and a bibliography. It is a draft and it says so.
Exploring a problem until it can be stated, then turning the statement into a goal. The fishbone, the why-what model, and the stakeholder table that has to sit beside the diagram.
Nine sources, IEEE style, linked to the record or the full text.
Several diagrams respond to a click. The intervention cycle explains each stage, the why-what model switches between the blank model and a worked case, and the stakeholder quadrants give a worked example.
The Shape of a Research Project
1. The Problem Comes First
Every research project starts with a gap. There is a situation we want, and there is the situation we have. When the two do not match, we say we have a problem. That word is not a complaint. It is the engine of the whole exercise.
Research exists to produce knowledge, insight, and information that move us across that gap. The idea is not mine. It belongs to Verschuren and Doorewaard [1], and it holds whether the gap is practical or fundamental. A production line that keeps stopping is a problem. So is a phenomenon nobody has yet explained. In the first case we want a new situation. In the second we want to close a hole in what is known. The method for approaching them is the same.
Most beginners rush past this step. They pick a method they like, or a tool they already own, and then look for something to apply it to. That is backwards. The context defines the problem, the problem defines the goal, and only then does the machinery follow.
2. Two Steps
Designing a research project splits cleanly in two.
The first step is the conceptual design. It answers what, why, and how much. What are we going to do, why is it worth doing, and how far will we go.
The second step is the technical research design. It answers how, where, and when. How will we gather what we need, where does it come from, and on what schedule.
The order matters. A technical design built before the conceptual design is a set of activities without a destination. It will look busy and produce nothing.
Figure 1. The two steps. The first fixes the destination, the second fixes the route.
3. The Conceptual Design
3.1 The Objective
The objective is the goal of the project. It states what we want to achieve.
It is not invented at a desk. It is fed by everything gathered during the problem analysis, and it has to connect to what the stakeholders actually want. An objective that ignores the people who own the problem is a private hobby.
3.2 The Research Framework
Next to the objective sits the research framework. Think of it as the shape of the project drawn out: the phases, and how one phase feeds the next. It is a conceptualisation of the whole route from where we stand to where the objective says we should end up.
3.3 The Conceptual Model
Alongside the framework we put our ideas into conceptual maps. This is the conceptual model. It names the elements at play, and it makes the relations between them visible. Vague thinking survives in prose. It rarely survives a diagram.
3.4 Questions and Sub-Questions
The objective and the research framework together produce the research questions. In a design project, they are design questions. Either way, they are the operational form of the goal.
Each question breaks down into sub-questions. Answer the sub-questions and you answer the question. Answer the questions and you reach the objective. That chain has to hold, link by link, or the project drifts.
3.5 The Theoretical Framework
Now comes the part I will repeat more than once, because it decides the quality of everything else.
The questions have to be answered with proper tools and methods. Those tools do not appear by inspiration. They come from a theoretical framework: the literature, and the accumulated experience of engineers and researchers who worked on similar ground before us. The right literature inspires enough tools and methods to answer the sub-questions. The wrong literature, or too little of it, leaves the project with questions it has no way of closing.
Getting this to the expected level is not decoration on a report. It is the difference between a project that can be executed and one that cannot.
3.6 Define and Operationalise
Put the pieces together, objective, research framework, conceptual model, questions and sub-questions, and the project is defined and operationalised.
All of it grows out of observable phenomena. The context supplies the raw material. We do not design an objective in the abstract and then look for a world to fit it.
Figure 2. The conceptual design. Read it left to right: the goal, the phases, the questions. The theoretical framework enters from below, and it is where the tools come from.
4. Context, Aim, and Contribution
4.1 Where the Problem Sits
The project context is the answer to a blunt question: where exactly is this problem located, and who carries it.
The answer points at a target. Sometimes the target is an individual. Sometimes it is collective. Naming it early prevents a great deal of confusion later, because a problem carried by one operator and a problem carried by a whole plant are not the same problem, even when the symptoms look identical.
4.2 Two Kinds of Aim
From the target, the project takes one of two directions.
Under a theoretical framework, the aim is to extend existing views or to build new theories. You are closing a knowledge gap.
Under a practical framework, the aim is to solve a practical problem, to create a new situation, or to instigate new developments. In engineering this usually means an artefact. You design something, you build it, and the situation afterwards is different from the situation before.
Neither is superior. They are different destinations, and they demand different designs.
Figure 3. Context, target, aim. The same problem can be entered from either branch, but the two branches end somewhere different.
4.3 Contribution
Contribution is a word we will use again and again, so it is worth fixing its meaning now.
Open almost any scientific paper. Near the beginning there is a paragraph, often a whole section, where the authors state what is new here. Not what the field knows. What they added, and why this work stands apart from everything published before it. That paragraph is the contribution, and writing it honestly is harder than it looks.
Your project has the same obligation. A problem is usually extensive or complex, and a fundamental question worth asking is rarely one that yields all at once. Our project contributes to the solution only partially, and often only indirectly.
That is not a failure of ambition. It is an honest description of scope. Reach the objective, answer the questions, and you have contributed to the field. Claim to have solved the whole problem and you are either working on something trivial or being dishonest about your boundaries.
Figure 4. Scope. The bracket is the honest claim; the arrow is what a single project actually delivers.
5. Types of Projects
5.1 Theory-Oriented Research
Theory-oriented work splits into two branches [1].
Theory development targets gaps in the construction of a theory.
Example: a gap closed
Through the 1960s, 70s, and 80s, string theory, the attempt to explain fundamental particles and matter as strings, drew enormous attention. By the early 1990s there were five competing versions of it. Five points of view on the same subject, and no way to reconcile them.
Then Edward Witten proposed a mathematical framework showing that the five were not rivals at all. They were variations of one general theory, seen from different sides. That is a gap in the construction of a theory, and closing it is theory development.
Theory testing sets out to test, adjust, or refine existing views. You are not building the theory again. You are finding out whether it holds.
Example: a theorem put under load
You can work out on paper how a robot will move faster and track a trajectory more accurately. You can prove a theorem and claim the performance will be stable.
Then you have to test it. First in simulation, where you see whether the theorem behaves as the paper says. Then, if you are serious, on the physical robot, which is harder, because now you need real parameters from a real machine and the world stops being cooperative.
The textbook was written with the social sciences in mind. This is my reading of it for control, robotics, and process engineering, and the logic survives the translation intact.
5.2 The Empirical Cycle and the Scientific Method
Two well-known routes serve both branches. The empirical cycle, from van Aken, Berends and van der Bij [2], starts with the choice of a phenomenon worth studying. Design the research, observe, induce toward theory, deduce hypotheses, test, evaluate, and return to the design.
The scientific method is the same animal under a different name. Make observations, ask why the pattern occurs, formulate hypotheses, develop testable predictions, gather data. Then comes the part people forget: a smaller loop inside the large one, where hypotheses are refined, altered, expanded, or rejected, and the data is gathered again. Only after that loop settles do you reach for a general theory.
Look closely at both and you will find the same logic proposed by different authors. Both are cycles. Neither ends. That is the point.
Figure 5. The empirical cycle, with the inner loop that most descriptions leave out. Hypotheses rarely survive their first contact with data.
5.3 Practice-Oriented Research
The problem solving cycle[2] begins with a problem mess: a practical situation, an engineering situation, that nobody has yet stated clearly. Defining it is the first task, and you cannot define what you do not understand.
Understanding is an active step, not a reading exercise. Can you reproduce the problem in a simulation environment? Can you go to the process, change a parameter, and watch the fault appear on demand? If you can make the problem happen when you choose, you understand it. If you cannot, you are still guessing.
From there: problem definition, analysis and diagnosis, a plan of action, the intervention, and the evaluation of results. Solving one problem creates new ones. That is how the cycle closes.
The intervention cycle[1] covers the same ground in five steps: problem analysis, diagnosis, design, change, evaluation. Compare the two and they are close relatives. The word that carries the difference is change, because change means something in the world now behaves differently. The process runs at a new operating point. The robot is faster. The artefact meets your specifications, or it does not, and the gap between what you specified and what you obtained is exactly what evaluation is for.
The intervention cycle comes out of the social sciences. I have introduced it here so that it also carries engineering problems and fundamental questions, and in my experience it carries them well.
Select a stage
Each stage has to settle something before the cycle is allowed to turn. Choose one on the diagram.
Figure 6. The intervention cycle. Five steps, and a sixth truth: the evaluation is where the next problem announces itself.
6. Naming a Cycle Is Not Enough
Here is the mistake I see most often, and it is worth a section of its own.
Asked what method they will use, students answer that their work follows the problem solving cycle, or the empirical cycle. Fine. That is true, and it is the right thing to state in a proposal. It is also nowhere near enough. A cycle is the general framework at the beginning of a project. It tells the reader almost nothing about what you are actually going to do on Tuesday.
Go to the literature and come back with tools and methods that real researchers have demonstrated on problems like yours.
Say you will model the process in Aspen and test scenarios for capturing carbon dioxide, because that is current technology and the software is built for it. Or say you will simulate the chemical process in MATLAB, because a specific author argues that route is better suited, or simply because you have the licence and the models exist. In operations research, name the linear programming formulation. In control engineering, decide whether the problem calls for linear or nonlinear control, and say what kind of mathematical model sits underneath.
The same applies on the theory side. If you are making observations, explain what makes those observations observable. If you are gathering data, say what data, and whether you will generate it, collect it, or simulate it. Say how you will validate an observation before you claim to have understood anything.
Cycles tell the reader what kind of project this is. Methods and tools tell the reader you can finish it.
Figure 7. Three levels of specificity. A proposal that names only the top level has described a genre, not a plan.
7. The Technical Research Design
7.1 Research Strategy
Strategy forces three decisions. Depth or wide range. How much data. What type of data, and how complex and available it is.
Choosing depth and breadth at the same time is the most common way to run out of time.
7.2 Research Material
Material means the research population: people, objects, situations, documents. It also means the gathering techniques, the methods and the tools. Simulation, pilot studies, experimental design, prototyping, rapid prototyping.
This is not a checklist to tick. The choice should be inspired by real projects, real problems that were already solved, and real questions that were already answered in part or in full. Somebody has done something close to this before. Find them.
7.3 Research Plan
The plan is the time schedule. Deadlines for the products and the deliverables, reporting included. A Gantt chart does the job well.
Build it once, properly, and you will keep using it. Not only for a research project, but every time you face a complex situation with a deadline attached. That skill outlives any single project.
Figure 8. The technical research design. Three decisions, in this order. The plan is last because it cannot be written until the first two are settled.
8. A Closing Note
None of this is bureaucracy. The structure exists because complex problems defeat people who improvise. Define the problem, state the goal, map the phases, ask answerable questions, borrow the right tools, then plan the work.
And remember what the diagrams in this chapter keep telling you. They are cycles. Solve a problem and new problems arrive. Answer a fundamental question and new questions arrive with it. That is not a sign the work failed. It is the work continuing, and the only real preparation is knowing it is coming.
The Problem and the Objective
The first chapter said that the objective is the goal of the project and that it is fed by the problem analysis. This chapter is that analysis. It covers the diagnosis, the tools that make a diagnosis possible, the problem statement that closes it, and the two ways of turning a statement into a goal.
1. Two Steps to an Objective
Formulating an objective takes two steps, and they run in order.
Exploration comes first. What problems are involved, and how complex are they. What is the background, which is to say the context. What do the stakeholders want, in their own words, before anyone translates it.
Formulation comes second. Now the researcher positions the work in time and in space. Is it realistic. Is it adequate. And a question people leave far too late: once the objective is achieved, how will anyone measure that it was.
Reverse the order and you get an objective that sounds impressive and rests on nothing.
Figure 9. The two steps to an objective. Exploration gathers the ingredients; formulation commits to a goal.
2. Exploration
2.1 What You Explore Depends on the Kind of Project
Exploration sets the problem context, and how you do it follows from the type of research.
Theory-oriented work runs on extensive literature research. You find the current subjects of discussion in the field, and from those you find the directions in which solutions might lie.
Practice-oriented work starts from a problematic situation, and you reach for a technique: the why-what model, the five whys, the five questions, a fishbone diagram, a stakeholder analysis. We will take three of these apart later in the chapter.
Note what does not change. Both branches demand serious reading. The literature is not a decoration on practical work.
Figure 10. Two routes through exploration. The techniques on the lower branch are interchangeable; the reading on the upper branch is not optional on either.
2.2 Why Solutions Fail
Watch enough projects and the failures start to rhyme. People do not fail because the problem was impossible. They fail for reasons that were visible from the start.
Some are not methodical. Some lack the commitment to see it through. Some misread the problem statement, usually because the diagnosis behind it was never done. Some lack knowledge of the techniques and processes involved, which means they needed to learn something before they began and did not. Some pick a method that has nothing to do with the problem in front of them, which is again a diagnosis failure. And some work from information that is insufficient or inaccurate, with no analytical thinking applied to it.
One thing addresses most of that list. Formulate the problem properly. To formulate it you need information, to gather information you need tools of diagnosis, and those tools have to fit the context of the problem.
Figure 11. Seven ways to fail, and the one piece of work that heads off most of them.
2.3 The Problem Statement
A problem statement is a concise description of the issues that have to be addressed before anyone tries to solve anything. One or two paragraphs. It is the capitalisation of the whole exploration phase, and it has to be connected to the context.
Its purpose is to focus attention. Not only the attention of the problem owner, but of whoever will execute the work, whether that is one person or a team.
An ill-defined problem is a signal, not a misfortune. It means the elements of the problem context have not all been gathered yet. Go back and gather them.
3. Read, Discuss, Report, Repeat
This is the mantra, and it is the whole working method of the exploration phase.
Read a great deal. Key journal papers, textbooks, patents, official reports from the company, the organisation, the university. Build a draft bibliography as you go. And let that bibliography show up throughout the document, not only in the introduction. It belongs in the diagnosis, in the statement of the goal, in the choice of methods and tools, and in how you define your deliverable and validate it.
Discuss once you have enough background to ask decent questions. Stakeholders first, for their desires. Daily supervisors, academic advisors, experts in the field.
Report, because this is what makes the difference. Weekly reports, the problem analysis, the project report, the presentation. These are official channels and they have to be written. Findings that stay in your head are not findings. Decide the outline of the story: diagnosis first, then the tools that produced it, then the goal, the questions, the methods.
Then repeat. One pass through this loop is never enough.
A word on order, because this is the most common mistake I see. If your stakeholder analysis appears after your problem statement, something has gone wrong. The analysis is one of the things that produced the statement. It cannot arrive afterwards to justify it.
Figure 12. The exploration loop. The arrow back from reporting is the one people skip, and skipping it is why a second pass never happens.
4. Three Tools
4.1 The Fishbone Diagram
The fishbone identifies possible causes for an effect or a problem. It belongs immediately after the interviews, the reading, and the brainstorming, and its job is to give all those loose causes a structure.
The classic version uses five categories: man, tools, environment, method, information. Do not treat that as fixed. One published study of obstacles to plastic recovery organised its bones around legislation, cost and capacity, technology, quality and demand, and market share. A study of storage tank accidents used eight. The categories come from the problem, not from the template.
One warning. The diagram does not license a guess. If you put a cause on a bone, expect to be asked where it came from. The literature, or the interview with the informant, the specialist, the problem owner. A fishbone full of unsourced assumptions is a drawing, not an analysis.
Figure 13. The skeleton, with the five classic categories. Replace them with categories that suit your problem, and hang one sourced cause on each stub.
4.2 The Why-What Model
The why-what model, proposed by Annamalai and colleagues [3], takes a rough first description of the problem and pushes it in two directions at once.
Upward it asks why do we want to solve this. That opens the broader problem, the context that makes the work worth funding.
Downward it asks what is stopping us from solving it. That opens the narrower problem, and this is where the technicalities live. Keep going down and you usually arrive somewhere very specific, which is exactly where a project can get a grip.
The model sits happily alongside a fishbone or the five whys. Use whichever combination makes the problem yield.
Figure 14. The why-what model. The worked case follows a laser system that could not meet its product requirements consistently. Draw your own version before you look at it.
4.3 Stakeholder Analysis
Stakeholders are the people with a stake in the project, through interest, through power, or through both. The analysis has two halves, and most people do only one of them.
The first half is positioning. For that we use Mendelow's diagram as presented by Ackermann and Eden [4]: interest on one axis, power on the other, four kinds of stakeholder in the quadrants. It tells you whose attention you must hold, whose you only need to keep, and whose absence from the room is survivable.
Select a quadrant
Each quadrant asks for different handling. Choose one to see it worked through on a production line bottleneck.
Figure 15. Mendelow's diagram. Position is not a property of a person; it is a property of a person and a particular project.
4.4 The Table Next to the Diagram
The diagram is the half everyone remembers. The table is the half that does the work, and it belongs on the page directly beside it. One without the other is not a stakeholder analysis.
Five columns. A number, so that the rest of the project has something to refer to. A name, and it has to be a real person rather than a role in the abstract, because roles do not hold opinions and people do. The function that person holds in the organisation. What that person wants, in their own words. And the technical requirement you derived from those words.
The fourth column is why you conduct interviews. Prepare your questions in advance, go and sit with the person, and write down what they say rather than what you expected to hear. You will get three kinds of answer. A few people hand you a technical requirement outright, already in numbers, and those people are a gift. Most hand you a wish. Some hand you a demand, or an anxiety, which is a wish with the temperature raised. Neither of the last two is SMART, and neither can be designed against.
Turning the fourth column into the fifth is the designer's work, and it is not a formality. It is where a vague sentence becomes a quantity a machine can be measured against, and it has to be written down. A requirement that lives only in your memory of the conversation is not a requirement.
No.
Name
Function
Desire, in their words
Technical requirement
S1
Anneke Bakker
Production manager
the line stops two or three times a shift and I lose most of a shift every week
Unplanned downtime below 2 per cent of scheduled shift time, measured over four consecutive weeks
S2
Rutger de Boer
Managing director
it has to pay for itself before the next budget round
Payback within 18 months at current production volumes
S3
Ilse Veenstra
Maintenance manager
whatever you put in, I do not want to be called out at night for it
Mean time to repair under 30 minutes, using no tooling beyond the standard set
S4
Marek Nowak
Shift lead, packaging
the operators should be able to clear a jam themselves
One operator clears a jam in under 3 minutes without removing a fixed guard
Not from the literature
You will not find this table in the sources behind this chapter. Mendelow's grid is well documented, and the move from desires to specifications is discussed in places, but the table as I am describing it, numbered, named, and carried through the whole project, comes from practice rather than from a paper.
I include it because in the projects I have seen it is the difference between a stakeholder analysis that shaped the work and one that was written afterwards to decorate it.
Now the part that is usually missed. During exploration the table helps you understand the problem, the system, and the requirements. That much is obvious enough. But the table does not stop working when exploration ends.
Once the objective is written, once the milestones are set, once the methods and tools are chosen, each of those decisions should trace back to a numbered row. The objective serves S1 and S2. This milestone exists because of S3. That tool was chosen because S4 needs an operator to clear a jam unaided. Run the trace and two useful things fall out. A decision that traces back to nothing is a decision you made for your own convenience. A row that nothing traces back to is a person you interviewed and then ignored, and they will notice.
Figure 16. Traceability. The tags above each box name the rows that choice serves. A box with no tag above it is a choice nobody asked for.
5. Formulation
5.1 Five Qualities
The textbook offers five tests for an objective [1]. It should be useful, which is to ask where the relevance lies and what the contribution will be. Realistic, which asks whether the system is well scoped or whether you have quietly taken on a larger one. Feasible, which asks whether you have the expertise, whether you need to learn new techniques first, and whether you can actually get at the data. Clear, which asks for precise language. And informative, which asks what new insight or knowledge the objective promises.
5.2 SMART
The second tool is SMART, proposed by Doran [5] and later refined by Bjerke and Renger [6].
Specific: aimed at one area of interest, or at a defined connection between areas. Given a large system, scope down to a subsystem.
Measurable: this is where the stakeholder analysis pays off, because you have already moved from vague desires to specifications that can be measured, and those specifications can go straight into the objective.
Attainable: reachable with the resources you actually have.
Relevant: with a clear contribution, whether that is insight, knowledge, or an artefact that solved the problem.
Time-bound: a reference date and a timeline, connected to the plan of the project.
5.3 The Two-Step Method
SMART is not a set of boxes to tick, and neither are the five qualities. Be smart about using it.
Bjerke and Renger [6] propose taking it in two steps, and the reason is worth understanding. Specific, measurable, and relevant all come directly out of the problem analysis and the problem statement. If you did that work, the information is already there. Attainable and time-bound are different in kind. They are negotiable, and more uncertain, because they depend on resources and on a schedule that has not been tested yet.
So settle the first three and write them down. Only then argue about what is attainable and by when. Trying to satisfy all five at once is how people end up with an objective that is precise about its deadline and vague about its purpose.
Figure 17. SMART taken in two steps. The crossing lines are the point: the letters are not in the order you should use them.
With a stated problem and a formulated objective, the ground is prepared. What follows is the work of turning that objective into research questions, laying out the research framework, and defining the concepts precisely enough that other people can use them.
Thinking in Systems
A confession about the order of this book. You have just read a chapter on analysing a problem and formulating an objective, and you are about to read a chapter about systems. In practice the sequence runs the other way. The system description belongs in the problem analysis, before the problem statement is written, because you cannot describe a problem without describing the thing the problem is happening inside. The last figure in this chapter shows where it really sits.
I have given it a chapter of its own for a simple reason. This is not one more technique to add to the fishbone and the why-what model. It sits underneath them. A system description can be what a fishbone is a fishbone of. It is a way of seeing, and it takes longer to explain than a tool does.
1. Why Talk About Systems At All
Systems analysis is largely a craft. Skilled people draw on the knowledge and the tools of many sciences and technologies to build something that answers to the needs of whoever will eventually use it [7]. That word, craft, is the honest one. It is not a procedure you execute.
More formally, systems analysis uses scientific methods to examine and structure complex systems inside a particular domain. It aims at an approach that is open, empirically grounded, and checkable by someone else, while accepting that complete certainty is not available [8].
Four things recommend the systems language.
It corrects for reductionism. Our models are always some distance from reality, and the complexity of the actors involved is rarely captured by taking the thing apart. Holism pulls in the other direction.
It attends to structure as well as process. You are not following a blueprint. Difficult problems deserve an approach chosen for them.
It is transdisciplinary. Electronics, mechanics, process engineering, industrial design, all brought to one problem so that the design that comes out of it is whole rather than partial.
And it gets closer to real problems. Models built this way sit nearer to the situation they describe.
The advantage is that a systems approach brings structure to problems that are complex and ill-defined. It forces you to state your assumptions and your expectations out loud, it gives you something to communicate with stakeholders about, and it comes with a large set of tools for building models of a domain. It will not hand you a definitive solution. It will let you eliminate the unfavourable alternatives, which is often the more useful service.
The limitation is incompleteness, and it is inherent rather than a sign of sloppy work. Practical constraints bite, not every factor can be considered, and decisions with long horizons and many actors add uncertainty that no diagram removes. Say so in your report rather than hoping nobody notices.
2. The System Diagram
The basic picture is a block with a boundary drawn around it. Inside are the internal factors, the things you are treating as part of the system. Entering from the left are the means, the levers you can actually pull. Leaving on the right are the criteria, the things you will measure. Coming down from above are the external factors, which influence the system and which you do not control [8].
The moment that diagram is filled in, a great deal becomes visible at once: what the problem is, what the objectives are, and what influences what.
Figure 18. The system diagram. What you can change enters on the left, what you will measure leaves on the right, and what you must live with comes down from above.
2.1 Four Words, Used Precisely
The diagram only works if these four are kept apart [8].
Interests
The values and desires an actor gives priority to.
Objectives
Those interests made situation-specific, concrete, and defined.
Criteria
The measurable factors derived from objectives that are otherwise abstract.
Means
The actions available to achieve a specific objective.
Notice that this is the same movement as the stakeholder table in the previous chapter. Interests are what people tell you in the interview. Criteria are what you wrote in the fifth column. The system diagram is where those criteria finally have somewhere to attach.
2.2 Building One
Four steps [8]. Set the initial problem demarcation and the level of analysis. Specify the objectives and the criteria. Identify the potential means, and map the main causal relations among the internal factors and their influence on the criteria. Then draw the diagram that gives an overview of the whole problem situation.
The first step is a means-ends analysis, and the rule of thumb is to start from the core desires of whoever owns the problem rather than from the first solution anyone proposed. The level at which you analyse the problem quietly determines which solutions are even thinkable.
The second step usually produces an objectives tree: a core objective at the top, and beneath it the two or three more specific things that would have to be true for it to hold. Good use of a metro line, for instance, resolves into many passengers, low operating loss, and low crowding, and those are things you can measure.
The third step is causal mapping, and it is messy the first time. Draw the factors, draw arrows between them, mark each arrow with a plus or a minus. The first attempt looks like a bird's nest. Then you find the loops, you find the factors nothing connects to, and you tidy it into something that will fit inside the boundary of your diagram.
3. The Scope, and Why It Is the Whole Point
A system almost never stays one system. Draw a hydrogen distribution line as compressors and buffers feeding a fuelling station, and it is a system. Look closer at that station and it contains heat exchangers, chillers, separators, purification. The station was a box; now it is a system of systems.
Which means the diagram has to say where you stop. Draw the subsystems, draw the interrelations, then mark the scope: the part of the system this project will actually touch.
Figure 19. Subsystems, and the scope drawn on top of them. Everything outside the red line is context you describe and do not change.
Why the scope is worth the effort
Once the scope is drawn on the block diagram, or the electrical diagram, or the flow diagram, three things that were floating separately lock together. The measurable objective. The technical requirements from the stakeholder table. And the boundary of what you are actually going to touch.
That is what makes an objective realistic and time-bound rather than merely worded that way. S1 says downtime below two per cent; the scope says you are working on subsystem S2; the objective says what S2 has to do for that number to be reached. Take away the diagram and the objective is a sentence with numbers in it. With the diagram, it is bounded, and you can defend it.
4. Hard and Soft
Not every problem calls for the same systems approach, and Jackson gives a way of telling which one you are in [9]. Two questions. How similar are the participants, and how complex is the system.
Participants means everyone with a stake, not only the researcher: the people with high interest, the people who set technical requirements. Judge them on three things, values, beliefs, and interests. Where those largely coincide, the participants are unitary. Where they do not, the context is pluralist, and the comfortable assumption that there is one agreed goal has to be abandoned.
Combine that with the complexity of the system and you get a grid.
Figure 20. Systems approaches against problem contexts. Locate your project here before you choose a method, not after.
Example: a project in the top left
Take a study of the thalamus acting as a controller for regions of the brain. There is one point of view in the room: control theory, mathematical modelling, numerical analysis. The participants are academics who broadly agree on what counts as an answer. One system is in play, and in the end one nonlinear model of it. No other engineering field is involved.
Unitary participants, a system that is not extremely complex. Hard systems thinking, and the methods follow from that.
Change one thing, put organisational systems or complexity theory into it, or bring in actors who disagree about what the problem even is, and the project moves out of that cell. The methods have to move with it.
5. The Systems Analysis Methodology
Jackson also sets out a methodology in three stages [9], and you will recognise the shape of it from the first chapter.
Formulation. Formulate the problem, and out of that come three things: the values and criteria of the participants, the objectives, and the boundaries and constraints.
Research. Identify, design and screen the alternatives. Then build and use models to predict the consequences of each, informed by some forecast of the contexts those alternatives will have to survive. This is where you generate or gather data, build a numerical model, and check whether it says anything true about the world.
Evaluation and presentation. Compare and rank the alternatives, communicate the results, evaluate the analysis itself, and then decide and implement. Afterwards, evaluate the outcome, which is not the same thing as evaluating the analysis.
Formulation, research, evaluation. Set that beside the empirical cycle and the intervention cycle and you are looking at the same skeleton in different clothes.
Figure 21. Three stages. The last box hides a distinction worth keeping: evaluating the analysis and evaluating the outcome are separate acts.
6. Choosing a Model
Once you know what your system is, two questions decide what kind of model can represent it. Are the variables deterministic, predictable from the laws of nature, or are they stochastic? And does the system depend on time?
Those two questions give four answers [9]. Deterministic and steady state gives you algebraic equations. Deterministic and dynamic gives you differential equations, linear or nonlinear. Non-deterministic and steady state gives you statistical and probability relationships. Non-deterministic and dynamic gives you discrete-event simulation, and there is a third question hiding in that cell: whether time is continuous or discrete.
Figure 22. Four kinds of analytic model. Ask which cell you are in before you choose a toolbox, not after you have already learned one.
7. Defining Concepts
One step remains before the technical design, and it is easy to postpone. Define your core concepts.
The temptation is to leave it until the research is under way. The reason not to is that the significance you attach to a key concept determines what material you will need to gather, and unexpected phenomena have a habit of arriving once the work has started [1].
These are stipulative definitions, which means they cannot be correct or incorrect. They can only differ from other definitions. What they can be is useful, and a definition earns its place by contributing to the objective. Three tests. Does it delineate, marking off what is inside the concept and what is not. Is it observable, which is to say operationalised into indicators, and those indicators are often precisely the technical requirements that came out of your stakeholder analysis. And does it link up to the research objective and the research questions, with enough feasibility that the answers can actually be obtained.
This is also why the objective has to be SMART. A concept defined into measurable indicators is what makes the measurable part possible at all.
From there we reach conceptual modelling: a set of assumed causal relationships between the core concepts of a project. A conceptual model is one of three things, or some combination. It can be descriptive, showing relationships between the objects, variables and entities of a system. It can be causal, showing only what drives what. And it is always an abstraction, a simplification of reality. Every model is wrong. The work is to be rigorously less wrong than the alternatives.
When you draw those causal relations, a handful of patterns cover most of what you need.
Figure 23. Five patterns of causal relationship. Most causal maps are these five, repeated.
8. Where All of This Sits
Here is the map, and it answers the question this chapter opened with.
Read it and you can see that the system description is not an appendix to the problem analysis. It sits inside it, next to the stakeholder analysis, and both of them come before the problem statement. The scope hangs off the research objective, because the scope is what makes that objective bounded. Defining concepts is the last thing you do while still in the conceptual design, and only then does the technical research design begin.
We cannot talk about the problem without the system, and if we are talking about a system it is because there is a problem. The chapter order in this book is a convenience. The map is the truth.
Figure 24. The conceptual design, in the order it is actually done. Everything inside the dashed line happens before a single decision about method or schedule.
References
Numbered in order of first appearance, in IEEE style. Titles link to the catalogue record or to the full text, and each entry carries a DOI where one exists; the two items without one predate the system. Software named in the text, such as process simulators and numerical computing environments, is not listed here.
[1]P. Verschuren and H. Doorewaard, Designing a Research Project, 2nd ed. The Hague, The Netherlands: Eleven International Publishing, 2010, ISBN 978-90-5931-572-3.
[7]W. Findeisen and E. S. Quade, “The methodology of systems analysis: An introduction and overview,” in Handbook of Systems Analysis: Overview of Uses, Procedures, Applications, and Practice, 1985, pp. 117–150.
An illustration, not a document. The paper on the desk is imaginary and so are the reviewer marks on it; the real ones are named below.
C. S. Lewis had a rule about reading. After a new book, do not allow yourself the next new one until you have read an old one in between. If one for one felt too strict he offered a fallback, one old book for every three new ones. The argument was not nostalgia. Every age is good at seeing certain truths and prone to certain mistakes, so the books that can correct our own period are the ones written outside it.
The line travels today in a shorter form, usually credited to Ivan Pavlov by accounts that never give a source. I have looked for one. Descartes made the same case three centuries before Lewis, describing good books as a conversation with the best minds of past centuries. The thought is old enough that ownership is the wrong question.
What nobody seems to have written is the version our trade needs. We do not read books. We read papers, and mostly recent ones, because that is what the field rewards. So here it is in our dialect.
If you want a new idea, read an old paper.
Below is what that cost me and what it bought.
The paper trail
In November 2023, three co-authors and I submitted a force-impedance controller in the port-Hamiltonian framework to IEEE Transactions on Control Systems Technology. We validated it on the Philips Experimental Robot Arm and compared it against the parallel force and position controller of Chiaverini and Sciavicco, published in 1993.
Five months later the decision came back. Reject, may be resubmitted.
“The most important drawback of the study is that an approach that is more than 30 years old was used as a baseline comparison. Although many other works built upon that baseline approach for 3 decades were briefly cited in the manuscript, it is odd to see that the comparison is still made over a 3-decade-old approach.”
Reviewer 7, on version 1, 27 April 2024
“Why are you comparing with literature from 1993 and 1994? Why not with more recent literature?”
Reviewer 4, same day
The associate editor agreed with both of them, and said the comparison diminished the effectiveness of our claims.
We spent the spring rewriting. New introduction, recent surveys, the energy-tank and geometric-impedance results, the learning-based adaptive work of the past decade. We did not change the benchmark. Our reply said why.
“While there have been many recent advances in the field of robotic arm control, many of these approaches still rely on underlying principles and methods similar to those proposed in earlier works.”
Our rebuttal letter, June 2024
Author #4 put it better in an email that month.
“I totally agree that the old papers are fundamental and this was the reason why they have been extensively cited in the first version. However, a more recent literature review was missing, but now everything looks ok.”
Author #4, 25 June 2024
We resubmitted in July. In January 2025 the paper was conditionally accepted, and the objection came back in capital letters.
“In the current version, although some more recent works were briefly cited, it is STILL odd to see that the experimental comparison is made over a 3-decade-old approach.”
Reviewer 1, on the second version, 8 January 2025
The associate editor quoted our own rebuttal sentence back at us, said the comparison remained limited in scope, and closed with a warning that rejection might still follow. I wrote to the other three the next morning.
“I see that, indeed, there is an issue we need to address again regarding comparing our approach to significantly older ones. But anyway, we still consider that this is a fair comparison.”
My email to the three co-authors, 9 January 2025
We submitted the last version in April 2025. The report that came back in August was one sentence long: the authors replied to all reviewer concerns. Accept without changes. The 1993 controller was still the comparison.
“Perseverance pays off, great!”
Author #3, 9 August 2025
“The concepts we developed continue to guide my current work on impedance control for humanoid robots.”
Author #1, two days later
The honest part
We did not win by refusing to read new work. We won by adding it. Between the first submission and the last, the paper gained a current literature review, a simulation study, a sampling rate, a wiring description, a public repository, a better video, and captions that explain why the arm stops short of the commanded position when it is pressing on a bar. All of that came from the reviewers, and all of it made the paper better.
One thing did not change. The controller we measured ourselves against was still the one from 1993.
Recent work told us where we stood. The old work told us what to beat.
That distinction is the part worth keeping. A literature review and a benchmark do different jobs. A review places you in a conversation, so it has to be current or it is simply wrong. A benchmark has to be the thing people still measure against, and that is a property time confers, not novelty. The reviewer who wrote that many other works had built on the 1993 approach for three decades was, without meaning to, making our case.
There is a failure mode on the other side and it deserves naming. Choosing an old method because it is easy to beat is not scholarship, it is theatre. The test is whether the old method is still the reference point people reach for. If it is, the comparison is fair. If it is not, you are shadow boxing. We argued it was, in writing, three times, and eventually an editor and three reviewers agreed.
So, the rule I would actually give a student. For every three conference papers you read, read one journal paper older than you are. Not out of reverence. The field’s blind spots are shared by everything published this year, including your own manuscript, and the only literature guaranteed not to have them is the literature written before they formed.
Ours is an age that is good at seeing what is new and liable to mistake recency for progress. The correction is cheap. It occasionally costs you two rounds of argument with a reviewer who thinks a date is an argument.
