University of Turku Robotics and Autonomous Systems Master’s Thesis Guide: DTEK1002, DTEK1105, 30 ECTS and UTUGradu

Quick answer: what is the University of Turku Robotics and Autonomous Systems thesis route?

The current Robotics and Autonomous Systems track in the University of Turku Master’s Degree Programme in Information and Communication Technology is a 120 ECTS, two-year Master of Science (Technology) programme in the Faculty of Technology. The controlling curriculum object is ICTRAS2427 / programme 99343 for 2024-2027. The exact thesis is DTEK1002 Master’s Thesis in Technology, 30 ECTS, graded 0-5. TTDK1308 is the 0 ECTS maturity examination. The track-specific seminar is DTEK1105 Master’s Thesis in Technology Seminar, Robotics and Autonomous Systems, 5 ECTS, Pass/Fail. DTEK1105 is listed under Other Studies and must not be counted inside the 30 ECTS thesis.

1. Start from ICTRAS2427 / programme 99343

Robotics and Autonomous Systems is one of the ICT specialisation tracks, but its curriculum must be read independently. The current Peppi object is ICTRAS2427 / 99343. Use that object and your own HOPS when planning the thesis. A sibling ICT track may share DTEK1002, but that does not mean its seminar code, module packaging, methods emphasis or optional-study placement automatically applies to Robotics and Autonomous Systems.

2. The degree is 120 ECTS even though Peppi shows 115-125

The formal degree is 120 ECTS. Peppi displays a technical root range of 115-125 ECTS because thematic/minor and Other Studies modules contain optional ranges. That range is a curriculum-tree selection mechanism, not a new degree size. Your HOPS should resolve the available choices into the approved 120 ECTS degree structure for your study right.

3. Understand the 80 ECTS Advanced Studies block

Peppi places 80 ECTS inside RASAS2427 Advanced Studies: a 20 ECTS Robotics and Autonomous Systems Core Module, 10 ECTS Compulsory Advanced Studies, 20 ECTS Common Studies in ICT, and the 30 ECTS thesis category. The first three coursework components total 50 ECTS, which aligns with the public programme description of 50 ECTS advanced-level major studies plus a 30 ECTS thesis.

4. Keep the 20 ECTS core, 10 ECTS advanced and 20 ECTS common blocks distinct

The core module contains Introduction to Mobile Robotics, Introduction to Robotic Manipulation, Robotic Localization and Mapping, and Computer Vision and Sensor Fusion. The 10 ECTS compulsory advanced block contains Robot Learning and Optimal Control. The 20 ECTS Common Studies area includes Capstone, Knowledge and Innovation Management and Finnish-language components. These blocks provide context for thesis methods, but none of them changes the DTEK1002 thesis credit.

5. DTEK1105 is a separate 5 ECTS seminar

DTEK1105 is the Robotics and Autonomous Systems thesis seminar. It is 5 ECTS, Advanced Studies, Pass/Fail, and available in English and Finnish. Peppi lists it under Other Studies rather than inside the compulsory thesis category or the 20 ECTS Common Studies category. Confirm its exact placement in your HOPS instead of assuming that the seminar is embedded in DTEK1002.

6. DTEK1002 is the exact 30 ECTS thesis course

DTEK1002 Master’s Thesis in Technology is 30 ECTS and graded 0-5. It requires scientific work, knowledge of the research field, command of appropriate research methods and scientific writing. A robot prototype becomes thesis evidence only when it is tied to a research problem, a documented method and a defensible evaluation. Building something technically impressive is not by itself the same as completing a scientific thesis.

7. Prepare the thesis plan with assigned supervisors

At the beginning of DTEK1002, prepare a thesis plan with the assigned supervisor or supervisors. When seeking a topic, contact a professor of the main subject so supervision can be arranged. State the engineering or scientific problem, platform, sensors, software, intended experiment or analysis, data source, evaluation criteria, risks, permissions and expected contribution. Update the plan when evidence or supervisor feedback justifies a change.

8. Company and University research-group theses are both possible

DTEK1002 explicitly allows a company or organisation challenge and can include company co-supervision alongside academic supervision. A thesis can also be completed inside a University research group. In either setting, clarify ownership of source code, robot logs, maps, camera recordings, partner data and hardware documentation before the project becomes dependent on material that cannot later be examined or published.

9. Know the examiner and final approval chain

At least two examiners evaluate the thesis using University grading guidance. Final acceptance and grading are decided by the head of the department based on the examiner evaluations. Seminar completion, thesis examination and degree-plan completion are therefore related but distinct administrative objects. Keep the examiner-ready manuscript, seminar work and HOPS records aligned so an otherwise complete thesis is not delayed by a missing course element.

10. TTDK1308 is the 0 ECTS maturity examination

The thesis category also contains TTDK1308 Degree Qualifying Examination for Master’s Degree, 0 ECTS. Normally the thesis abstract or another suitable part serves as the maturity test. A conditional written-exam route can apply depending on prior degree and Finnish or Swedish educational-language background. Check your own case rather than copying the route followed by another student.

11. Use DTEK1105 as a development process

DTEK1105 is designed to support the thesis, not merely to provide a final presentation. It asks students to analyse a previous related thesis, present their own thesis near completion, participate in peer presentations and complete a written research-methods exercise. The planned workload is 135 hours. Use the seminar to test whether your research question, chosen evidence and claimed contribution actually fit together.

12. Define the evidence type before choosing the robot or algorithm

A Robotics thesis may centre on mobile navigation, manipulation, SLAM, perception, sensor fusion, robot learning, control, embedded systems, hardware acceleration, multi-robot coordination or another bounded problem. First define what evidence could answer the research question. Only then choose the robot platform, simulator, dataset, sensors, controller or model. Tool choice should follow the question rather than becoming the question.

13. Separate simulation evidence from physical-system evidence

DTEK2100 explicitly uses simulation environments and physical robotic platforms. Simulation is valuable because it allows controlled and repeatable experiments, but a simulated success supports a claim about the model and simulated conditions. If the thesis claims real-world robustness, validate on relevant physical hardware or clearly state the simulation-to-real boundary. Do not describe a simulator result as physical validation by implication.

14. Freeze the robot configuration before comparison

Record the robot model, hardware revision, sensors, actuator limits, firmware, operating system, middleware, library versions and important configuration parameters. If physical payload, wheel type, manipulator tool, battery condition or controller frequency affects the outcome, record those too. A later software update or calibration change can alter performance enough to make a comparison invalid unless the tested configuration is reconstructable.

15. Mobile-robot evaluation needs multiple layers

DTEK2100 covers sensing, probabilistic localisation, mapping, motion planning, trajectory optimisation and reactive navigation. These layers should not be collapsed into a single claim such as “the robot navigates well.” A useful evaluation identifies which layer is being tested, what input it receives, what metric captures its performance and what other layers remain possible explanations for system-level failure.

16. Treat localisation, mapping and SLAM as related but distinct claims

DTEK2102 focuses on localisation, mapping and SLAM, including probabilistic state estimation and graph-based optimisation. A visually plausible map does not automatically prove accurate localisation. Report the environment or dataset, sensor suite, ground-truth source where available, trajectory characteristics and the error definition. Loop-closure behaviour, map quality and trajectory error are different forms of evidence and can disagree.

17. State how ground truth was obtained

If you report localisation or trajectory error, explain whether ground truth comes from motion capture, a calibrated external system, dataset reference poses, high-grade positioning or another source. If no ground truth exists, say so and avoid reporting an indirect proxy as if it were position truth. Ground-truth uncertainty can matter when the performance difference between two methods is small.

18. Sensor fusion requires calibration and timing context

Computer Vision and Sensor Fusion covers cameras, radar, LiDAR, calibration, stereo vision and multi-source fusion. For a fusion thesis, document sensor modalities, coordinate frames, calibration or registration procedure, synchronization assumptions and the stage at which information is fused. Calibration drift or timestamp misalignment can look like an algorithmic error, so preserve enough information to separate data-quality problems from method performance.

19. Bound computer-vision claims to the tested conditions

Perception performance can change with lighting, weather, camera placement, motion blur, occlusion, background and scene type. If the experiment uses frames from the same recording session, prevent near-duplicate or sequence leakage between development and final evaluation. Object detection, segmentation, tracking and pose estimation are different tasks. Use metrics that correspond to the actual task and deployment question.

20. Manipulation evidence needs kinematics, dynamics and task criteria

DTEK2101 covers forward and inverse kinematics, Jacobians, dynamics, trajectory generation, motion planning and robot control. Report coordinate frames, robot model, controller, target trajectory, payload and task-success rule. An inverse-kinematics solver converging does not prove that the motion is collision-free or dynamically feasible. Likewise, reaching one pose does not establish reliable manipulation across the intended workspace.

21. Separate controller performance from task success

A controller can have low tracking error while the overall task still fails because perception, planning or grasping is wrong. Conversely, a task may succeed despite poor transient control. When control is central, report the relevant tracking error, overshoot, settling behaviour, control frequency, actuation limits and operating range. Use task-level success as an additional system measure rather than a substitute for controller evidence.

22. Planning algorithms need declared assumptions

DTEK2101 includes sampling-based planners such as RRT and PRM. If the thesis compares planners, state the map or configuration space, collision checker, cost function, termination condition and computational budget. A feasible path is not automatically optimal, and a fast solution in one environment does not imply superiority across all planning problems. Repeated trials are important where the planner is stochastic.

23. Robot-learning experiments need a clean evaluation boundary

DTEK2103 covers data-driven perception and decision-making, reinforcement learning, system-dynamics learning, self-supervised learning and emerging models. Separate training data, tuning or development evidence, and final evaluation whenever possible. Repeatedly changing the model after inspecting the final trajectory or test environment can turn the final evidence into another development set and overstate generalisation.

24. One reinforcement-learning seed is not enough for a stability claim

Reinforcement-learning outcomes can vary with random seeds, initial states, exploration and environment stochasticity. Preserve the reward definition, observation and action spaces, training budget, environment version and seed policy. If a conclusion depends on average performance, report variability across runs rather than selecting one favourable policy. A high return also needs interpretation in terms of the actual robotic objective.

25. Keep simulation-trained policy claims separate from real-world validation

Robot Learning includes both offline and interactive learning and commonly uses simulation for training or evaluation. A policy that performs well in simulation is evidence about that simulated distribution. If the contribution claims physical deployment, test the relevant real platform or explicitly discuss the sim-to-real gap. Differences in dynamics, latency, sensing and unmodelled disturbances can materially change policy behaviour.

26. Document demonstrations for imitation learning and VLA work

DTEK2103 introduces imitation learning and Vision-Language-Action models. For imitation learning, document where demonstrations came from, who or what generated them, coverage of the task space and preprocessing. For a VLA system, preserve the model/version, prompts or instructions, observations, action interface and task protocol. Model output is behaviour under those conditions, not proof of general autonomous competence.

27. Separate perception-model evidence from downstream control

A learned perception model can improve benchmark accuracy while the closed-loop robot still performs poorly, or vice versa. If both perception and control are part of the system, evaluate them at appropriate levels. Report perception metrics on defined data and separately report closed-loop task performance. This makes it possible to identify whether a failure is caused by sensing, representation, planning, control or integration.

28. Embedded-system correctness is not the same as real-time correctness

DTEK8146 covers embedded-system architecture, RTOS concepts, hardware/software co-design and low-power devices. Passing functional tests shows that the implementation produced expected outputs for those tests. It does not prove that deadlines are met under the required workload. If the thesis makes real-time claims, define the scheduling assumptions, measurement method, control period and timing evidence that support them.

29. Measure power and energy instead of inferring them

A device being embedded, edge-based or FPGA-accelerated does not automatically make it energy efficient. If power or energy is part of the contribution, define what is measured, where, at what workload and for how long. Distinguish instantaneous power, energy per task and total system energy. Performance-per-watt claims should use the same task and comparable accuracy or quality constraints across systems.

30. Heterogeneous computing comparisons need end-to-end boundaries

DTEK8147 covers CPU-GPU and CPU-FPGA systems, parallel programming, scheduling and performance optimisation. Record the platform, software stack, workload size and measurement boundary. Include data-transfer and setup overhead when the claimed benefit is end-to-end latency. A kernel-level speedup alone can be misleading if communication or preprocessing dominates the complete robotic pipeline.

31. FPGA acceleration has several separate outcomes

DTEK8148 covers FPGA design flow, high-level synthesis, resource utilisation and hardware acceleration. Latency, throughput, logic/DSP/memory use, clock rate, numerical precision and power are different properties. A design can improve one while worsening another. If comparing HLS variants or FPGA against CPU/GPU execution, hold the model or algorithmic task constant and state any precision changes that affect output quality.

32. Edge-AI claims must identify where computation happens

DTEK8149 connects System-on-Chip technology with edge computing, edge AI and robotics. State which processing runs on the robot, which runs on a nearby edge device and which, if any, uses a remote service. Include communication latency and bandwidth assumptions if they affect control. An “edge” label is not a method by itself; the scientific claim should identify the measurable systems trade-off.

33. Safety cannot be inferred from task success

A robot completing a navigation or manipulation task does not by itself establish safety. For physical experiments, define relevant hazards, speed or workspace limits, emergency-stop or containment arrangements and who may enter the test area. If humans participate or work nearby, the research design may need additional ethics, permission or risk controls. Bound safety claims to the actual analysis and test evidence collected.

34. Protect people and property during physical testing

Experimental autonomy can fail in unexpected ways. Use a test environment appropriate to the platform and avoid exposing uninvolved people or property to unbounded risk. Validate low-level controls and emergency procedures before high-autonomy trials. Record material safety interventions as part of the method because they can affect results, especially when human takeover or safety stops change the measured task-success rate.

35. Camera, audio and trajectory data can be personal data

Robotics datasets can capture faces, voices, precise movement traces, device identifiers or contextual information about individuals. Removing names does not necessarily make such data anonymous. Define what is collected, why it is needed, who can access it, how long it is retained and what can be published. If a person can reasonably be re-identified, treat the data accordingly rather than relying on a filename change.

36. Company and partner material may need a publication boundary

A company thesis may involve source code, floor maps, credentials, device configurations, proprietary hardware data or operational logs. Decide early what belongs in the public manuscript, what can be supplied to examiners through an approved process and what must remain protected. Reproducibility can use synthetic fixtures, redacted configurations or bounded descriptions when publishing the original material would breach confidentiality or privacy.

37. Capstone and Internship do not replace DTEK1002

DTEK0088 Capstone is a 10 ECTS engineering project course, and DTEK0045 Internship can provide work-life experience under Other Studies. Either can inspire a thesis topic or provide access to a platform or partner problem. Neither automatically satisfies DTEK1002. A thesis still needs its own research question, plan, scientific method, evidence, analysis and examiner-ready written report.

38. Build a robotics reproducibility manifest

Preserve a compact manifest that links the research question to robot/platform configuration, firmware and software versions, code revision, dataset or log snapshot, simulator/environment version, calibration, parameters, random seeds, evaluation scenarios and generated outputs. For hardware measurements, include the compute platform and relevant clocks or power settings. The aim is to make the path from input to claim traceable.

39. Reproduce one headline result from a clean state

Before freezing the manuscript, regenerate one central trajectory plot, SLAM error table, perception result, manipulation success rate, RL benchmark or hardware-acceleration measurement from the preserved inputs. Check that code revision, configuration, dataset and aggregation rules match the thesis. If the regenerated value differs materially, investigate the cause instead of manually editing the final table to match an earlier screenshot.

40. Report variability and failure modes

Physical robots, stochastic planners and learned policies can vary from run to run. Where variation matters, use repeated trials and report how results were aggregated. Do not hide failed trials that are relevant to the stated protocol. Failure categories can be more informative than an average success rate because they reveal whether weaknesses arise from perception, localisation, planning, control, hardware or interaction with the environment.

41. Use AI under the DTEK1002 disclosure rule

DTEK1002 allows generative-AI tools but requires their use to be documented clearly enough for the student’s own contribution to be identified and graded. Validate AI-generated code, explanations, references and analysis against execution and primary sources. Do not upload protected source code, credentials, private logs, unpublished partner material or personal sensor data to an uncontrolled AI service.

42. Distinguish AI as the research object from AI as an assistant

Robot Learning can make AI itself part of the scientific object, while the student may also use an AI assistant for coding or writing. Describe these roles separately. A learned controller or VLA model needs model, dataset, training and evaluation evidence. AI used to help write code or prose needs disclosure, verification and academic-integrity controls. One role does not validate the other.

43. Turnitin checks originality, not robotics validity

Turnitin is mandatory in the University thesis process, but similarity checking does not validate SLAM accuracy, controller stability, robot safety, perception generalisation or reproducibility. Treat originality and scientific validity as separate controls. A low similarity score cannot compensate for an uncontrolled experiment, and a technically sound experiment still needs correct citation and attribution.

44. UTUGradu is the institutional submission route

UTUGradu manages higher-degree thesis submission, originality checking, examination, approval, electronic publication and archiving. Before upload, make sure the examiner-ready manuscript matches the final evidence, the confidentiality boundary is settled and the required originality process is complete. Recheck current UTUGradu operational instructions near submission because interfaces and workflow details can change independently of the 30 ECTS thesis rule.

45. A practical mobile-robot and SLAM thesis workflow

Define the navigation or mapping question, freeze the robot and sensor configuration, establish calibration and ground truth, choose representative trajectories or datasets, implement the baseline, run the proposed method under the same protocol, preserve raw logs, calculate declared metrics, inspect failure cases and reproduce one result. Conclude only at the level supported by the tested environments and sensing conditions.

46. A practical manipulation and control thesis workflow

Define the manipulation task and workspace, document the kinematic/dynamic model, choose the controller or planner, specify payload and safety limits, establish baseline behaviour, run repeated trials, measure tracking and task outcomes, analyse failures and check whether results change across relevant operating conditions. Keep planning, control and task-level evidence separate so the contribution remains identifiable.

47. A practical robot-learning thesis workflow

Define the task and deployment distribution, preserve training data or simulator version, declare observation/action spaces and reward or supervision, separate tuning from final evaluation, run multiple seeds when stochasticity matters, compare with a meaningful baseline, test real hardware if making a physical-deployment claim, and retain enough artifacts to reproduce at least one headline result from the frozen configuration.

48. Final Robotics and Autonomous Systems checklist

Confirm ICTRAS2427 / programme 99343, the formal 120 ECTS degree, the 80 ECTS Advanced Studies structure, DTEK1002 30 ECTS, TTDK1308 0 ECTS, and DTEK1105 5 ECTS Pass/Fail under Other Studies. Then audit supervisor/examiner steps, simulation-to-real boundaries, platform versions, calibration, repeated trials, safety, privacy, partner confidentiality, reproducibility, AI disclosure, Turnitin and UTUGradu. If a claim extends beyond the tested platform or environment, either add evidence or narrow the claim before submission.