PHYSICAL PROTOTYPING

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

AGENDA

Messages

Project planning and prototyping Using prototypes in concept evaluations Digital Fabrication

Electronics

Supervision after lecture

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

MESSAGES

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

THE ITPDP PROJECT

==> picture [634 x 357] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

THE ITPDP PROJECT

==> picture [634 x 357] intentionally omitted <==

==> picture [35 x 35] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

THE ITPDP PROJECT

From Brightspace under “ITPDP 2026” Presented at first lecture about course introduction

Eligibility for exam

To be eligible for the exam, each student must hand in all tooling exercises and supporting assignments, and every group must hand in the final report, be represented in the plenary sessions, and - of course - the exam related demo session and oral exam.

Goals and requirements for the final project

The IT product must be placed clearly in relation to one of the three subthemes (or have deviation agreed upon with course educator).

The group must demonstrate an understanding of the target user group's needs and conditions, using theory and tools introduced in this course, and/or theory/tools presented earlier in their study programme.

The solution must position itself as relevant to the future users, utilizing ethnomethodological work and user-centered design to ensure validity. A successful evaluation is however not a requirement, but reflection and analysis of validity, process and outcome is the main end result.

The context of use and the challenges identified in the user studies must be taken into account.

The solution must include multiple clients/components and the cloud (typically via web technology). Several subcomponents and resources that can communicate, e.g., a system with a mobile app, a physical installation, and with automatic storage of sensor data in the cloud.

The IT product may involve a smartphone as part of the solution, but there must be an interaction with physical/tangible components in the environment or on the user, which you have designed and fabricated yourself.

Arguments must be made based on the needs of the users, usage of theory and methods, and the business potential in relation.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

WORKLOAD AND EXPECTATIONS

Euro ean standard: 1 ECTS = 25-30 hours of work. p

For Aarhus University, it has been set at 28 hours.

ITPDP is slightly different.

First part (seen as a 5 ECTS course): 140 hours per person, including lectures/TØ, from 26th of January to 17th of March.

Second part (seen as a 15 ECTS course): 420 hours per person, including lectures/TØ, from 18th of March to June 17th. This is equal to a minimum of 32 hours per week. The rest of the course schedule is exam period and exam preparation time.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

WORRYING TENDENCIES

Resource hour overview:

Estimated teaching time: 68-70 hours, not including supervision.

1 person group: The overall project should reflect 490 hours of work. 2 person group: The overall project should reflect 980 hours of work. 3 person group: The overall project should reflect 1470 hours of work. 4 person group: The overall project should reflect 1960 hours of work.

In the current state, your project should currently represent roughly 230 hours per person. For a three person group = 425 hours of work (30% deducted, prioritization)

Can you honestly say that you have put this time into the project, preparation, lectures, reading etc.? If yes, then great!

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PROJECT PLANNING

A course. university

Project planning and implementation is part of the learning outcomes – we cannot guide and/or hand-hold you the entire way.

Make sure to keep yourself updated via the Course Schedule on Brightspace. Please ignore all other sources, as mentioned multiple times.

Be present… We cannot teach or supervise students who do not show up.

You can technically stay away from now until final report and exam, as long as Interview Assignment and Tooling Exercises are done. But don’t.

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PHYSICAL PROTOTYPING

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

MVP

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

“… Version of a product with just enough features to be usable by early customers”

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

MINIMUM VIABLE PRODUCT (MVP)

Often a term used in “Agile Prototyping”.

A way to create clear goals to be able to evaluate/validate a prototype/concept.

What is the minimum features our prototype needs to have, in order to solve the identified problem and/or answer the research question?

Build towards simplistic representations of your vision – not individual small parts.

==> picture [613 x 98] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

Agile Prototyping for technical systems – Schuh et al.

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

BUT HOW DO YOU PLAN THIS?

==> picture [713 x 300] intentionally omitted <==

https://activecollab.com/blog/project-management/moscow-method

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

MOSCOW EXAMPLE - KITCHEN TIMER

• • Time can be set (up to two hours) Timer can be set (up to 24 hours) - - Hours and minutes are separate Hours, minutes and seconds - - The user gets notified User gets multimodal feedback - - The timer can be reset Multiple concurrent timers - - Timer can be paused Small enough to carry - - Fits in the kitchen Battery lasts for full longitudinal - Battery lasts more than max. timer study duration Must have Should have - - Timer = multiple weeks? Could have Will not have Cloud-connection - - Smartphone connected Statistics and food categorization - - Contextual multimodal feedback Credit-card like footprint - Fusion sensing (thermometer?) - Solar panel

But… how do we prioritize these??

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

HOW TO PRIORITIZE POST MOSCOW

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

HOW TO PRIORITIZE IN MOSCOW

Aim high, scope appropriately – you should push yourself. Free Features First

Impact-analysis (Remember scenarios? Personas? Contextual Design?) The art of choosing the right ecosystem/backbone Pessimistic approximations

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

AIM HIGH, SCOPE APPROPRIATELY

Push yourselves, but lean into your skillset.

Always scope based on project goals (in this case course goals and delimitations). Do not let an overly simple MVP set you back.

An MVP is built to be your fallback – leave it alone, document, take pictures, make videos. Your MVP is then baseline for next iteration.

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

IMPACT ANALYSIS

Focus on scenario-based design and contextual design – use it!

Which features will have the most (positive) impact?

You understand your user and the context – use the analysis to strengthen arguments for feature prioritization.

==> picture [356 x 119] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

IMPACT ANALYSIS - KITCHEN TIMER

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

“FREE FEATURES FIRST”

Free features are not necessarily free, but requires very little technical reiteration.

Hardware vs. software Simple additions or changes

==> picture [254 x 210] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [140 x 153] intentionally omitted <==

==> picture [135 x 114] intentionally omitted <==

==> picture [191 x 144] intentionally omitted <==

==> picture [135 x 114] intentionally omitted <==

==> picture [258 x 199] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

IMPACT ANALYSIS - KITCHEN TIMER

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

https://www.uxpin.com/studio/blog/design-sprints/

TIME AND SPRINTS

A gile development methodologies often refer to the term “sprint”.

I strongly suggest using this approach for testing feasibility in feature-based prototyping.

Suggested framework for prototype sprint: Inspired by the often used “5-day design sprint” (or similar artzy naming scheme) Following MoSCoW prioritization and free-features-first analysis. Have initial brainstorm about implementation strategy. Divide most crucial features up, and sprint them in pairs. Work 24-72 hours on each feature depending on impact (two features being worked on simultaneously). End with feasibility assessment and construct time plan based on last sprint. Or scrap.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

PROTOTYPE EVALUATION

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

THE FALLACY OF FLAWLESS

Prototypes are inherently flawed.

Small factors and variance makes a difference for replicability and comparability.

The obvious end-goal is a self-sustained and robust system.

Often that is not the case… and maybe not the best and easiest way to add additional features?

DEPARTMENT OF COMPUTER SCIENCE

==> picture [184 x 183] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

WIZARD OF OZ

==> picture [518 x 357] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

https://www.nngroup.com/articles/wizard-of-oz/

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

FINISH, FIDELITY, FEEDBACK

Maryam Tohidi, William Buxton, Ronald Baecker, and Abigail Sellen. 2006. Getting the right design and the design right.

and

End goal of a prototype evaluation:

• To validate concept

• Evaluate user appropriation

• Problem-solution fit

• Feedback on future iterations

Prototype fidelity matters!

==> picture [131 x 206] intentionally omitted <==

Youn-Kyung Lim, Erik Stolterman, and Josh Tenenberg. 2008. The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas.

Users find it easier to critique lower fidelity prototypes.

Sometimes using multiple low-fidelity, feature-focused prototypes is the right way… … For evaluation J

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

DIGITAL FABRICATION

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

MANUFACTURING METHODS

Additive Manufacturing Subtractive Manufacturing 3D printing as example CNC (Computer Numerical Control) millin as exam le g p Adding layer by layer Taking away layer by layer Material base = often lastic Material base = often metals/wood p Often used for fast initial rotot in Often used for sturd construction p yp g y

==> picture [152 x 152] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

Combo = Hybrid Process

==> picture [184 x 185] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING 13. APRIL 2026

SIMON HOGGAN CHRISTENSEN LAB COORDINATOR

AARHUS UNIVERSITY

Meh?

1. What type of features does your product have?

• small organic and intricate features → additive methods

• large or sharp features, drilled and tapped holes or other fastening features →subtractive methods

2. What type of material do you want to work with?

• thermoplastics and resins → additive methods

• materials like metals, wood, or foam → subtractive methods

3. How many units do you want to produce?

• low-volume production or iterative prototyping → additive methods

• large-volume production runs → subtractive methods

• Meh?

RAPID PROTOTYPING

Purpose: Rapidly creating tangible artifacts or prototypes to filter/validate certain aspects.

Addendum: In house. By yourself. Something you hopefully made. Without ruining yourself… … or the equipment J

Most common practice and understanding: Utilizes digital fabrication, due to speed and work/process synchronizity.

Any fabrication occupying more than a few days is no longer rapid prototyping – it’s invested construction.

Invested construction is not a bad thing – perfect for prototyping towards final demo. Rapid prototyping is your tool to quickly test, validate and scrap. Anything too detailed - and invested - in can become hard to scrap.

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

RAPID PROTOTYPING

Mastering techniques, process, equipment = Absolute control regarding time and scope

DEPARTMENT OF COMPUTER SCIENCE

==> picture [446 x 441] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO

DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AGENDA

• Why Arduino for prototyping

• Alternative prototyping platforms (and what you will be taught about in other courses)

• Code examples

• ESP32 Wizard of Oz

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO AS PROTOTYPING PLATFORM

Readily available here and big part of our lab-ecosystem

Lots of documentation and code examples + tutorials

Easy prototyping, hook-up, HATs, powering etc.

Many variations, sizes and beefiness

==> picture [251 x 251] intentionally omitted <==

Often limiting: CPU/GPU power, threading/cores, memory, GPIO pin amount, buffer sizes, communication.

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

ALTERNATIVE PLATFORMS

Wemos D1 Mini (cheap WiFi board based on ESP8266)

ESP 32 (great platform with lots of possibilities)

RPI (when you want something in between a PC and an Arduino) ATMEL MCU family (used in PhysComp. When you want to create custom circuits) NUCs/Smartphones (for webapps/apps, graphics-intense tasks)

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO IDE

~~Arduin~~ o is an open-source electronics platform based on easy-to-use hardware and software. https://www.arduino.cc/en/software

==> picture [708 x 285] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ESP32

~~ESP32~~ is widely used in System-on-Chip (SoC) solutions designed for Internet of Things (IoT) applications due to its:

• Integrated WiFi and Bluetooth

• Lower power consumption with deep sleep modes

• More I/O Features (than Arduino)

==> picture [264 x 263] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

PINOUTS?

==> picture [558 x 400] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ESP32

==> picture [737 x 374] intentionally omitted <==

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO V.S. ESP32 V.S. ESP8266

==> picture [850 x 352] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO COMPONENTS

DEPARTMENT OF COMPUTER SCIENCE AARHUS UNIVERSITY

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

COMPONENTS – WHAT OPTIONS DO WE HAVE?

• ~~Many~~ components will be covered in Physical Computing next semester: - Entire lecture set on sensors and what types we have in lab as inspiration. Engineering Interactive Technologies delves further into making novel sensing techniques.

• Entire lecture set on actuators – even more time to delve into actuators in Multimodal Interaction and Shape Changing Objects and Spaces

• For now: Use Johannes’ component inspiration kit and chomskylab.dk – and talk to supervisors/TAs/Labtools for further advice/inspiration.

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARDUINO CODE EXAMPLES

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

ARDUINO CODE EXAMPLES

“AnalogInOutSerial.ino”

“Arrays.ino”

”Smoothing.ino”

“switchCase.ino”

WiFi network examples (third-party examples)

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

ANALOGIN OUTSERIAL

Example of map Example of analogRead Example of Serial.print

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ARRAYS

Array example because slightly different syntax compared to java

DEPARTMENT OF COMPUTER SCIENCE

SIMON HOGGAN CHRISTENSEN LAB COORDINATOR

PHYSICAL PROTOTYPING 13. APRIL 2026

AARHUS UNIVERSITY

RUNNING AVG

”Smoothing.ino” in Arduino--> Examples Running average data smoothing Useful for sensor and input with noise Noise = variance in data without change in input

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

SWITCHCASE

Crucial for ITTT cases and sensing

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

ESP32 EXAMPLE – YOUR WOZ CHEATSHEET

ESP32 is a brilliant platform for the Wizard of Oz method.

Example code in Brightspace.

Simple UI via WiFiServer à interaction with ESP32 Easily adaptable.

Of course only used for evaluation and prototyping, not the final demo J

==> picture [216 x 390] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

INSTALL THE ESP32 BOARD IN ARDUINO IDE

• Open IDE and go to Tools > Board > Boards Manager

• Search "ESP32", select " esp32 by Espressif Systems ", and click Install

• Reopen Arduino IDE

• Under Tools>Board you should see esp32 à ESP32 Dev Module option

==> picture [224 x 449] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

INSTALL USB CABLE DRIVER

~~Downl~~ oad Link: https://www.silabs.com/developer-tools/usb-to-uart-bridge-vcp-drivers

• Windows Users: The Arduino Installer should install the USB Driver automatically. But in case it doesn't work, download from the link. Windows 10 users should use CP210x Universival Windows Driver , and Windows 8.1,8 and 7 users can use CP210x Windows Driver.

• MacOS Users: Download the CP210x VCP Mac OSX Driver . After installing, accept Privacy changes and prompts. If install fails, install legacy driver variant.

• Testing if the USB driver works (all OS): in the Arduino menu Tools>port before plugging in your ESP with the USB cable. You should see either none or one entry listed. Now plug in your ESP microcontroller and take another look at Tools>port . You should hopefully see one more entry. On Windows this will often be something like COM3 . On Mac it will be USB_to_UART or cu.usbserial

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

TESTING AND GETTING INFO

• Open FileàExamples à Basics à BareMinimum and test that upload works to your ESP32.

• During upload the device MAC adress will be written (including other useful info)

==> picture [613 x 162] intentionally omitted <==

• Now it’s time to get on WiFi, by either using your phone hotspot as WiFi, or connect to AU-IoT via Simon (bring him your device MAC address)

==> picture [43 x 44] intentionally omitted <==

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

GETTING ON WIFI

include const char ssid = "AU-IoT"; const char password = "test1234"; void setup(){ Serial.begin(921600); delay(1000); WiFi.mode(WIFI_STA); //Optional WiFi.begin(ssid, password); Serial.println("\nConnecting"); while(WiFi.status() != WL_CONNECTED){ Serial.print("."); delay(100); } Serial.println("\nConnected to the WiFi network"); Serial.print("Local ESP32 IP: "); Serial.println(WiFi.localIP()); }

DEPARTMENT OF COMPUTER SCIENCE

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

void loop(){}

Or your phone hotspot SSID + pass

==> picture [43 x 44] intentionally omitted <==

AARHUS UNIVERSITY

GETTING ON WIFI

• Result 1:

==> picture [613 x 108] intentionally omitted <==

• Result 2: Endless connecting loop (retry SSID/pass or another WiFi)

• Result 3: Connection failed (retry)

• Result 4: Gibberish (check baud rate).

DEPARTMENT OF COMPUTER SCIENCE

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

REACTING TO ONLINE INPUT

• Open the .ino file from Brightspace called ”ESP32_WifiWorkshopFinal” (unedited code can also be found via link, remember to change SSID credentials and baud).

• Read through to understand what it does. It is a very basic HTTP-request ”ESP32 as web server”-setup, and is great for future prototyping!

• Set up a breadboard with your ESP and two LEDs to pin 26 and 27 (remember a 220 ohm resistor to each + GND pin)

• Use your computer/phone to control the pins (write the IP in the URL-field in a browser)

• Optional - IoT Doorbell: Edit the code to work with a single buzzer instead of two LEDs – maybe even make a little melody?

DEPARTMENT OF COMPUTER SCIENCE

Idea and code from: https://randomnerdtutorials.com/esp32-web-server-arduino-ide/

==> picture [43 x 44] intentionally omitted <==

PHYSICAL PROTOTYPING SIMON HOGGAN CHRISTENSEN 13. APRIL 2026 LAB COORDINATOR

AARHUS UNIVERSITY

==> picture [176 x 88] intentionally omitted <==