Skip to content
Documentation
April Robots Documentation

April Robots Documentation

Introduction

April Robots – A Web System for Robot-Assisted ASD Therapy for Children

This document describes technical and non-technical details of the April Robots project, including terms, background information, system overview, and references for other parts of the documentation.

Non-technical terms

  • Web system – A set of interrelated web-based applications accessible via an internet browser.
  • ASD (Autism Spectrum Disorder) – A developmental disorder characterized by challenges in social interaction and communication.
  • Social robots (hereinafter “Robots”) – Robots designed for social interaction. In this project, we currently use Furhat and NAO. These robots can collect analytical data using computer vision. Note: We do not control the robots’ core software and only interact with their provided APIs.
  • Robot activities – Predefined scripted movements and audio performed by the robots.
  • Robotherapy – In this context, the use of social robots for therapeutic purposes, particularly to develop cognitive skills in children with ASD. A robotherapy session involves the execution of specific robot activities.
  • Centers for children with ASD (hereinafter “Centers”) – Specialized facilities (similar to kindergartens) that support the development of children with ASD. Staff includes both specialists who work with robots and those who do not.
  • Center specialists working with robots (hereinafter “Specialists”) – Center staff responsible for conducting robotherapy sessions using social robots and this system. Specialists typically have limited technical expertise.

Stakeholders

Centers, Specialists (primary offline users), Parents and Caregivers (hereinafter “Parents”), and Researchers (analytics and studies).

Project goals

Develop a reliable and maintainable system that enables:

  • Specialists to conduct and review robotherapy sessions, manage children in their Center, and access assistive robotherapy-related information.
  • Parents can track their children’s developmental progress across multiple Centers and access robotherapy-related guidance.
  • Researchers collect and analyze data on children’s progress and performance based on feedback from Specialists, Robots, and Parents.

Core requirements

  • User-friendliness – Intuitive UX for users with limited computer experience.
  • Multilingual support – English, Russian, and Kazakh languages.
  • Reliability – Minimize system errors and unexpected behavior (especially for robots).
  • Maintainable – Prioritize code readability and maintainability.
  • Scalable – Use scalable frameworks/libraries for future development.

Background / History

This project originated as a research initiative by Anara Sandygulova (Associate Professor at the Robotics Department) several years ago. Over time, numerous contributors have worked on various aspects, including methodology, content development, funding, and software.

Olzhas, Salauat, and Yerassyl joined the project in Fall 2024 as a Computer Science capstone project. Their primary objective was to redesign legacy applications to enhance usability and functionality. In Spring 2025, Olzhas and Salauat decided to continue the project with Professor Anara. During Summer 2025, Alikhan and several interns joined the project, and the project was renamed to April Robots. Since fall 2025, many developers worked in teams led by Temirlan and Bibarys (Fall 2025), then Dana and Sherkhan (Spring 2026 onwards). In parallel, Zhannur (Cozmo) and Yasmin (April Hub) have been leading their projects as well. Since 2026, all these teams have become a part of the larger April Hub ecosystem.

System Overview 

    ---
config:
  themeVariables:
    fontSize: 14px
  flowchart:
    htmlLabels: false
    diagramPadding: 45
    nodeSpacing: 30
    rankSpacing: 60
  layout: elk
title: April Robots — Online & Offline Architecture
---

flowchart TB

subgraph OffApp["Offline App on PC"]
  Podman
  BackCore
  Storage2[("Static Storage")]
end

subgraph Podman["Podman — Containers with FastAPI microservices"]
  ms1["Robot MS 1"]
  ms2["Robot MS 2"]
  ms3["Robot MS 3 ... N"]
end

subgraph BackCore["BackCore — FastAPI host"]
  dbms[("DDB — File-based DBMS")]
  compFront["Static Front (compiled SvelteKit → HTML, JS, CSS)"]
end

subgraph Pod1["1xPod"]
  Front["Frontend"]
  FrontComment["SvelteKit -> NodeJS, Full-Stack NodeJS app"]
end

subgraph Pod2["1xPod"]
  Back["Backend"]
  BackComment["FastAPI"]
end

subgraph Pod3["1xPod"]
  DB[("MongoDB")]
end

subgraph k3s["k3s"]
  Pod1
  Pod2
  Pod3
end

subgraph OnlineApp["Online App on Virtual Server"]
  k3s
  Storage1[("Static Storage")]
end

BackCore --- compFront & dbms
Front <-- API --> Back
Back -- queries --> DB
Back --- Storage1
BackCore <--> ms1 & ms2 & ms3 & Storage2
OneSpecialist["Specialist"] <-- uses --> compFront
Users["Specialists, Parents, Admins"] <-- uses --> Front
rob1["Robot 1"] <--> ms1
rob3["Robot 2"] <--> ms2
rob2["Robot 3 ... N"] <--> ms3
Back <-- sync: cloud --> BackCore
rob1 <-- sync: robots --> BackCore
rob2 <-- sync: robots --> BackCore
rob3 <-- sync: robots --> BackCore
FrontComment@{ icon: "fa:comment", pos: "b"}
BackComment@{ icon: "fa:comment", pos: "b"}
Users@{ icon: "aws:res-users", pos: "b"}
OneSpecialist@{ icon: "azure:users", pos: "b"}
rob1@{ icon: "aws:arch-category-robotics", pos: "b", h: 48}
rob2@{ icon: "aws:arch-category-robotics", pos: "b"}
rob3@{ icon: "aws:arch-category-robotics", pos: "b"}

Core components

  • Online application
    • Data on centers
    • Data on all sessions for all children
    • Data on all children across all centers
    • Aggregated analytics per center/child/activity, etc.
    • Administration of available activities
    • Administration of all online app users
    • Different user roles have different levels of access and edit data
    • Study curriculum management
    • Collecting parent’s feedback on children’s progress
  • Offline application
    • Administration of center’s children
    • Data on center’s children
    • Data on sessions of the center
    • Aggregated analytics per child
    • Robots FAQ
    • Data on available activities
    • Controlling robots
    • Collecting specialist and robot feedback on children’s performance during activities
    • Tracking children’s long-term progress
  • Synchronization

Technical terms

  • Source frontend – source code in SvelteKit for a frontend.
  • Compiled frontend – source code compiled via Vite to either static files or a NodeJS app.
  • Offline backend — backend of the offline app.
  • Podman – docker analogue without a running background daemon.
  • WSL – Windows subsystem for Linux. WSL is required for Podman.
  • Offline app core — offline backend + compiled offline frontend. No podman, no wsl, no microservices.
  • Offline app full (aka AR Offline) — offline app core + microservices + podman + wsl.
  • Action script (aka action file, robot script) — a python file that uses a robot’s API library in Python to perform an action.
  • Robot metrics – robot MS collects raw data when users run action scripts via offline app core. Raw data then is processed by the MS into usable robot metrics. Robot metrics are used to calculate children’s development progress.
  • Installer app – an application that installs a new version of the offline app. Installer app is not part of the offline app.
  • Launcher app – an application that launches the installed offline app. The launcher app is not part of the offline app.
  • Robot microservice (Robot MS) — an app shipped as a docker image, runnable through podman, that works with a specific type of robot and an offline backend; not called a container, not called robot agent or agent. Example: NAO MS.
  • Online frontend – compiled NodeJS full stack application that is responsible for the frontend of the online app.
  • Online backend — entire online backend including the sync module, but usually the sync module will not be relevant to the context of the discussion.
  • Sync module (SM) — not a microservice, not a container/pod, but a contained module within the online backend. SM operates as part of the backend.
  • Online app (aka AR Online) — online backend + online frontend.
  • GHCR — GitHub Container Registry. Our own registry inside Novators-kz organization, where docker images are stored.
  • Migration process – a process of moving data from one form to another, in particular in a database.
  • Init migrations – a type of migrations; used to update data in online/offline databases when database schemas change. Init migrations export functions used to convert existing data into the new format.
  • Sync migrations – A type of migrations; used to convert data incoming from offline apps to newer formats to upload to the online database.
  • Synchronization process – Two-step process of synchronizing data between an offline database and the online database, and of uploading to robots everything that is required to be present on the robots from the online app.
  • Robot files (RFs) – files that have to be put on robots’ OS in a specific location for the offline application to work properly.
  • Robot ideal state (aka ideal state) – data containing the list of all necessary RFs for each robot and their location.

Further read

Core components of the system defined in other parts of the documentation:

DocumentationApril Robots Backends