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 optionallyREPO
) variables at the top of the pi-gen stage script atstage-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
Manual Build (Recommended for testing)
- Go to Actions tab
- Select "RasQberry Pi Image Release"
- Click "Run workflow"
- For dev branches:
- Leave version blank (auto-generated)
- Check "Force cache refresh" if needed
- For main and beta branch:
- Enter semantic version (e.g., "1.2.3")
Build Performance
Build Type | Cache | Typical Duration | When to Use |
---|---|---|---|
Dev (cached) | β | ~21 minutes | Regular development |
Dev (fresh) | β | ~65 minutes | Monthly or forced refresh |
Production | β | ~65 minutes | Official 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:
- Frontmatter (Optional): YAML configuration enclosed in
---
. This section specifies metadata and page attributes. - 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
- Fork the repository and create your feature branch.
- Commit your changes with a descriptive message.
- Push the branch to your fork and create a Pull Request.