Tips and Tricks from Jan

===

On this page, you will find various tips & tricks from Jan for building the 3D model (e.g. slightly modified STL files, useful tools), installing and using the SW stack and the quantum computing demos, and for modifications of the SW stack and adding new demos to the platform.

3D model

I have slightly modified some of the STL files to create a specific variant of the RasQberry Two model or to adjust them a bit to my environment (e.g. the specific 3D printer I use, etc).

STL files will be added soon

Standalone model

The "standalone model" does not use the floor at all. The intention is to use multiple of these standalone models to resemble the modular structure of Quantum System Two, i.e. being able to rearrange the elements and build larger quantum computing structures. For that case, the holes for the screws have been removed. Also, we do not use the double wide version of the RTEs, but only the small RTEs, which then have four magents (two on each side). This allows more flexible configurations.

LED Filter Screen

The bill-of-material mentions a "welding shield" than can be used in front of the LEDs. Instead, you can 3D print it - with the right material. Many black filaments will not work as they absorb too much light, but a screen printed with 0.6 mm Prusament PLA Galaxy Grey does just fine. STL file is here, and removes the need for a separate order of a welding shield and cutting it.

Polarisation of the Magnets

SW Developer Infos

Forking the repo

If you fork the repository, you’ll need to update two files to reflect your GitHub user, branch, and repo name:

  • The on: trigger in .github/workflows/RQB-image.yaml (around line 15).
  • The GIT_USER, GIT_BRANCH (and optionally REPO) variables at the top of the pi-gen stage script at stage-RQB2/01-install-qiskit/01-run-chroot.sh.

Iterative Development of RQB2_menu.sh

The complete GitHub actions workflow to build a new SW image takes about 70 minutes. To speed up iterations when modifying RQB2_menu.sh (and related files) at run-time, the following approach can be used to "dynamically" update the files in RQB2-bin and RQB2-config in a running system:

export GIT_REPO="https://github.com/JanLahmann/RasQberry-Two.git" # modify to match your development repo export GIT_BRANCH="JRL-dev02" # modify to match your development branch export CLONE_DIR="/tmp/RasQberry-Two" export FIRST_USER_NAME="rasqberry" export RQB2_CONFDIR=".local/config" git clone --branch ${GIT_BRANCH} ${GIT_REPO} ${CLONE_DIR} cp ${CLONE_DIR}/RQB2-bin/* /home/${FIRST_USER_NAME}/.local/bin/ cp -r ${CLONE_DIR}/RQB2-config/* /home/${FIRST_USER_NAME}/${RQB2_CONFDIR}/ sudo cp ${CLONE_DIR}/RQB2-bin/* /usr/bin sudo cp -r ${CLONE_DIR}/RQB2-config/* /usr/config rm -rf ${CLONE_DIR}

Build System

Automated Image Building

The RasQberry-Two project uses GitHub Actions to automatically build custom Raspberry Pi OS images.

Build Triggers

  • Automatic builds: Push to any dev* branch
  • Manual builds: Use the "Actions" tab β†’ "RasQberry Pi Image Release" β†’ "Run workflow"

Build Types

  • Development builds (dev* branches): Use caching for faster iteration (~21 min)
  • Beta builds (beta branch): Full clean build (~65 min)
  • Production builds (main branch): Full clean build (~65 min)

Caching System

Development builds use a sophisticated caching mechanism:

  • Base OS layers (stages 0-4) are cached monthly
  • Only the RasQberry-specific stage is rebuilt
  • Force refresh: Use refresh_cache option in manual workflow

Version Management

  • Main branch: Requires semantic versioning (e.g., 1.2.3)
  • Beta branch: (tbd)
  • Dev branches: Auto-generated as branch-YYYY-MM-DD-HHMMSS

GitHub Actions Workflows

.github/workflows/RQB-image.yaml - RasQberry Image Build Workflow

Quick Start

  1. Go to Actions tab
  2. Select "RasQberry Pi Image Release"
  3. Click "Run workflow"
  4. For dev branches:
    • Leave version blank (auto-generated)
    • Check "Force cache refresh" if needed
  5. For main and beta branch:
    • Enter semantic version (e.g., "1.2.3")

Build Performance

Build TypeCacheTypical DurationWhen to Use
Dev (cached)βœ“~21 minutesRegular development
Dev (fresh)βœ—~65 minutesMonthly or forced refresh
Productionβœ—~65 minutesOfficial releases

Website development

This repository powers the RasQberry Two documentation website, built using Next.js and deployed via GitHub Actions.

Features:

  • Dynamic Content: Markdown-based pages rendered as part of the website.

  • Customizable Frontmatter: Define page metadata like titles, leadspaces, and table of contents settings.

  • Modern Tooling: Leverages Next.js for static site generation and optimized builds.

πŸ“š How to Add Content

The website builds its pages dynamically from the content folder. Each Markdown file in this folder corresponds to a page on the site, maintaining the folder's route hierarchy.

Markdown File Structure

Each Markdown file consists of:

  1. Frontmatter (Optional): YAML configuration enclosed in ---. This section specifies metadata and page attributes.
  2. Content: The main body written in standard Markdown syntax.

Frontmatter Attributes

Here’s a breakdown of available attributes for configuration:

leadspace: title: string # Title of the page copy: string # Subtitle or description size: tall | short | super # Height of the leadspace section cta: # Optional Call-to-Action configuration primary: label: string # Button text url: string # Button URL icon: logo-github | arrow-right # Icon for the button bg: # Optional background settings image: src: string # Image URL alt: string # Alt text for the image tableOfContent: disabled: boolean # Disable TOC for this page (true/false) default false minLevel: number # Minimum header level to include in TOC maxLevel: number # Maximum header level to include in TOC

Additional Markdown Features

You can enhance your Markdown files using custom directives:

Embedding YouTube Videos

Embed a YouTube video by adding the following directive to your Markdown file:

::youtube[Description of the video]{#video-id}

Example:

::youtube[Video of a cat in a box]{#2yJgwwDcgV8}

🀝 Contributing

Bug Reports and Feature Requests

We welcome contributions! If you encounter a bug or have ideas for new features, please open an issue here.

Submitting Changes

  1. Fork the repository and create your feature branch.
  2. Commit your changes with a descriptive message.
  3. Push the branch to your fork and create a Pull Request.

🧩 Resources