Group work and collaborators
This concept was developed during the first Social Robot Design session as part of Group 1. The aim of the session was to explore an ill-defined case, select useful design methods, create a first problem-space mindmap, identify possible building blocks, and translate the concept into an initial functional breakdown and experimental approach. This fits the course's focus on designing tools and methods for social robot design, rather than immediately building a final robot.
Collaborators:
Maurits Dijkman, Bianca Filip, Ewoud Janus, Emilia Pavel, Rebecca van der Lee, and Gijs Vis.
My contribution:
During the session, I was involved in all parts of the group work: defining the pet anxiety case, formulating the research question, discussing the selected design tools, creating the mind maps, identifying possible building blocks, and developing the experimental approach. After the session, I further developed the material for my own portfolio by rewriting and structuring parts of the text, improving the figure captions, and adding extra explanation where needed to make the assignment clearer and more complete.
Case description
Domestic pets, such as cats and dogs, can experience stress or separation anxiety when they are left alone or when they enter a new home. This makes the case relevant for social robot design, because the robot would not only need to “do” something, but also interact in a way that is understandable, safe, and appropriate for the animal.
Existing interactive toys and pet technologies may help in some cases, but their effectiveness depends strongly on the individual animal. A movement, sound, smell, or toy that is exciting for one pet might be frightening or overstimulating for another.
Because of this, designing a fixed robot companion for pets is difficult. Instead of designing a single finished robot, our group focused on a modular pet companion toolkit. This toolkit would allow designers and pet owners to rapidly prototype, test, and adapt different types of pet–robot interactions. Possible modules include a treat dispenser, a laser pointer, a moving tail, a sound/light module, or a mechanical arm for moving toys.
The goal is to discover which combinations of behaviour, movement, reward, and interaction style could support play, comfort, or anxiety reduction for a specific pet.
Research question:
How can a modular robotic design toolkit enable designers and pet owners to rapidly prototype interactions that may help reduce anxiety-related behaviours in domestic pets?
Quick literature check
To position our case academically, we looked at literature around three connected areas: pet anxiety, Animal-Computer Interaction, and robotic or interactive companion systems.
Ogata describes canine separation anxiety as an anxiety-related disorder that appears when the owner is absent or perceived to be absent, and notes that although it has been widely discussed for decades, prevention and treatment are still difficult. This supports our assumption that pet anxiety is not a simple problem with one universal solution. (ScienceDirect)
Lenkei et al. show that separation-related behaviour in dogs can be linked to different inner states, such as fear, panic, or frustration. This is important for our case because the robot should not treat all “anxious behaviour” as the same thing. Different emotional states may require different forms of interaction, or no interaction at all. (PMC)
Sargisson’s review suggests that behaviour modification, especially systematic desensitisation, is one of the more successful treatment directions for canine separation-related problems. For our toolkit, this means the robot should not be framed as a cure, but as something that could support careful, gradual, and testable interaction routines. (PMC)
Mancini’s Animal-Computer Interaction manifesto argues that ACI studies the interaction between animals and computing technology in the contexts where animals habitually live, act, and socialise. This matches our decision to design around pets in the home, rather than only around the owner’s expectations. (Open Research Online)
Mancini also argues for an animal-centred ethics framework in ACI, where animal welfare is treated as a fundamental requirement. This is especially relevant for our case, because playful interaction should never come at the cost of stress, fear, or unsafe behaviour. (ScienceDirect)
Hirskyj-Douglas et al. review ACI research after the original manifesto and show that technologies for animals include tangible, physical, and interactive systems. This supports our modular toolkit direction, because our concept combines physical modules, sensors, movement, and interaction design. (MDPI)
The DogPhone project by Hirskyj-Douglas explores a dog-to-human video call device and reflects on animal agency, power relations, and how difficult it is to measure animal user experience. This is relevant because our toolkit also needs to consider whether the pet has control, choice, or the ability to disengage from the interaction. (Enlighten Publications)
Krueger et al. review human–dog relationships as a framework for robotic dogs, showing that appearance and behaviour influence how people interpret robotic dog-like systems. Although our robot is meant for pets rather than humans, this still helps us think about embodiment, behaviour, and expectations. (PMC)
Together, these sources support our approach: instead of assuming one robot behaviour will help every pet, we propose a modular design toolkit that allows different interactions to be tested, compared, and adapted to individual animals.
Selection of useful design tools
During the session, we randomly drew three method cards from the User Innovation Toolbox to explore how different design methods could help us approach our case. Figure 1 shows the front side of the three selected cards: Wizard of Oz, Hackathon, and Online Cohort Analysis. Figure 2 shows the back side of these cards, which provided extra explanation and inspiration for how the methods could be applied. We used these cards as a starting point to discuss what each method could teach us about designing a modular toolkit for pet anxiety.
Wizard of Oz
Method:
Puppeteering is used to test a product’s behaviour by manually simulating it before building a fully working system.
Application to our case:
Before building the toolkit, we can create a low-fidelity version of the pet robot and manually control its movements, sounds, and interaction modules. This allows us to test different speeds, movement patterns, distances, and play behaviours without committing to a final hardware design.
What we might learn:
This method can help reveal which interactions are playful, calming, boring, or frightening for pets. For example, jerky movement, unexpected sounds, or unfamiliar shapes might scare an animal, while slower movement or familiar play patterns may invite interaction. Puppeteering also helps translate play behaviour into mechanical design requirements.
Hackathons
Method:
A hackathon is a short, intensive collaborative design event where participants rapidly ideate and prototype possible solutions.
Application to our case:
We could organise a one-day hackathon with students, designers, engineers, and animal enthusiasts. Participants would use available sensors, actuators, cardboard, Arduino components, and pet-safe materials to prototype possible modules for the toolkit.
What we might learn:
A hackathon could generate many different module ideas in a short time. It could also reveal practical design challenges, such as durability, safety, scale, material choice, and whether the toolkit is intuitive for other designers to use.
(Online) cohort analysis & churn
Method:
Cohort analysis groups people or cases based on shared characteristics, so patterns can be compared.
Application to our case:
We could study different groups of pet owners, for example, owners of rescue animals, young pets, older pets, cats, dogs, or pets with separation anxiety. This could be done through online forums, surveys, or interviews.
What we might learn:
This could help us understand what commonly triggers anxiety, how owners currently respond, what types of toys or behaviours animals prefer, and which signals might indicate stress, curiosity, or playfulness.
Figure 1. Front side of the three randomly selected User Innovation Toolbox cards.
Figure 2. Back side of two selected User Innovation Toolbox cards, showing additional method information.
Mindmap of problem space
Figure 3 shows the first mind map we created during the brainstorm. The central question was "How can I invite you to play?" From there, we explored different ways a robot could create playful interaction, such as movement, sound, toys, light, smell, personality, and familiar behaviours. The mindmap also includes directions such as companionship, helping, and training, which helped us think beyond simple entertainment.
This brainstorm helped us move from the broad idea of anxious pets at home towards a more specific design direction: a modular toolkit for testing which types of interaction may feel playful, calming, or engaging for a specific pet.
Figure 3. Initial problem-space mindmap created during the group brainstorm. The mindmap explores how a robot could invite an animal to play through movement, sound, toys, light, smell, personality, and companionship.
Potential building blocks
In addition to the first mindmap about the problem space, we also created a second brainstorm during the session that focused on the question: "How can I invite an animal to play?" Figure 4 shows this brainstorm. Instead of starting from technical components, we first explored possible forms of interaction, such as movement, reward, toys, sound, smell, light, personality, and mimicking familiar human or animal cues.
This helped us move from playful interaction ideas towards more concrete building blocks for the modular pet companion toolkit. For example, the ideas of reward, movement, light, and sound can be translated into modules such as a treat dispenser, moving tail, light feedback, speaker, or toy mechanism.
The toolkit could consist of several interchangeable building blocks.
Main platform
- Controlled base or class robot platform
- Sturdy chassis
- Microcontroller, such as Arduino or Raspberry Pi
- Battery pack in a safe enclosure
- Lights and a speaker for feedback
Actuators and movement
- Servo motors
- Simple moving tail
- Small arm or open-source arm structure, such as SO-ARM100
- Drivable base
- Toy movement mechanism
Pet-facing modules
- Treat dispenser
- Laser pointer
- Ball or toy launcher
- Moving tail or feather module
- Sound module
- Light module
- Soft or fur-covered exterior parts
Sensor input
- Microphone for detecting barking, meowing, purring, or other sounds
- Proximity sensor for detecting approach or avoidance
- Camera for detecting the pet, toys, or movement
- Optional touch or contact sensor for detecting physical interaction
Materials
- Cardboard for low-fidelity prototypes
- 3D-printed parts
- Pet-safe casing materials
- Treats and toys
- Fur or soft materials for embodiment testing
Figure 4. Building-block brainstorm created during the group session. The mindmap explores different ways a robot could invite an animal to play, including movement, reward, toys, sound, smell, light, personality, and emotional needs such as anxiety, boredom, stress, and loneliness.
Functional breakdown
The toolkit first needs to sense the pet’s behaviour. This includes detecting proximity, sound, movement, and interaction attempts, so the system can recognise whether the pet is approaching, avoiding, playing with, or ignoring the robot.
After sensing the behaviour, the system needs to interpret the pet’s state. Based on the available input, it could estimate whether the pet seems curious, playful, avoidant, stressed, or inactive. This interpretation does not need to be perfect at the start, but it helps define what kind of response the robot should give.
The next function is to select an appropriate interaction. Depending on the pet’s behaviour, the toolkit could choose between play, calming behaviour, reward, mirroring, or stopping the interaction completely.
The robot then needs to act or respond through one or more modules. It could move, make a sound, show light feedback, give a treat, move a toy, or activate another interaction module.
Over time, the toolkit should also be able to adapt its behaviour. It could store preferences and avoid behaviours that previously caused fear, avoidance, or stress. This is important because every pet may respond differently to the same interaction.
Finally, the system needs to fail safely. This means stopping movement when needed, avoiding overheating, disabling unsafe modules, and preventing chewing hazards. This makes the concept clearer as a way of testing interaction possibilities, not only as a plan for building a robot.
Potential experimental approach
To explore the first encounter between a pet and the robot, we propose a low-fidelity bodystorming and puppeteering exercise. One team member acts as the domestic cat, while another team member acts as the robot using a physical proxy, such as cardboard or a simple robot-shaped object.
The aim is not to realistically imitate an animal perfectly, but to reveal possible interaction problems early. For example, the exercise can help us explore whether the robot moves too quickly, blocks the pet’s path, feels threatening, gives unclear feedback, or invites rough interaction. The rest of the group can observe, film, and take notes for later analysis.
Figure 5 shows an example of how a team member can act as a physical proxy for an animal. In this case, Maurits imitates a seal to explore how body posture, movement, and physical behaviour can be used in a theatrical exercise. This connects to our proposed experiment, where acting and puppeteering help us test pet–robot interactions before building a final system.
This fits the course direction because the slides introduced testing combinations such as real robot/real user, fake robot/real user, real robot/fake user, and simulated robot/simulated user. It also connects to the use of improv theatre and wizarded robots as tools for exploring social robot behaviour before building a final system.
Experimental planning over 14 weeks
Because the project runs over 14 weeks, the experimental approach should leave enough time for development, building, iteration, testing, measuring, and validation. Since we do not yet know the exact planning of the course or how the semester will develop, the following timeline is a possible planning rather than a fixed schedule:
Weeks 1-3: Case study and gap identification
We define the pet anxiety case, collect literature, identify direct and indirect stakeholders, and explore the problem space through mind maps and brainstorming. The main goal is to understand which part of designing a pet companion robot is difficult and where a design toolkit could be useful.
Weeks 4-7: Tool development and early prototyping
We develop the modular toolkit concept further. This includes selecting possible modules, building low-fidelity prototypes, exploring Wizard of Oz or puppeteering setups, and testing simple interaction ideas such as movement, light, sound, treats, and toy-based behaviours.
Weeks 8-10: Application and evaluation
We apply the toolkit to the pet anxiety case. This means using the toolkit to test or compare different pet-robot interaction ideas. We can evaluate both the interaction outcome and the toolkit itself: did it help us make better design decisions, and was it useful as a method?
Weeks 11-12: Report and presentation
We document the design tool, the case, the experiments, the design decisions, and the results. We also prepare the final presentation or demonstration.
Weeks 13-14: Buffer, refinement, and final portfolio work
These weeks can be used for final improvements, extra testing if needed, cleaning up documentation, refining visuals, and making sure the group work and personal portfolio clearly show the process and contribution.
Figure 5. Seal (left) and Maurits (right), demonstrating a low-fidelity physical proxy for animal behaviour in a bodystorming exercise.
Pitch slide
Although the updated assignment description does not explicitly require a pitch slide anymore, we still included the original pitch slide from the session because it summarises the concept clearly.
Figure 6 shows the pitch slide for the Pet Anxiety Toolkit. It summarises the core idea of the concept: a modular robot companion toolkit that allows designers and pet owners to test different interaction modules for anxious pets. The original slide is also available on Canva: https://canva.link/el69kek0ztsmts0.
Figure 6. Pitch slide for the Pet Anxiety Toolkit (PAT), summarising the concept of a modular robot companion toolkit for testing different interaction modules for anxious pets.
Reflection
This first session helped us shift from thinking about "what robot should we build?" to "how can we find out what needs to be built?" That distinction is important because pets have different preferences, fears, and play behaviours. What feels playful or calming for one animal might be boring or frightening for another. A modular toolkit could make it easier to test different interaction ideas before committing to a final robot design.
The most useful insight for me was that the robot does not need to be fully functional at the start. By using puppeteering, low-fidelity prototypes, and acted scenarios, we can already discover important design constraints, such as movement speed, safety, material choice, and how a pet might respond to different modules. This makes the toolkit useful not only as a possible robot concept, but also as a design method for exploring pet-specific interactions.