From 528bc91a47feb348c7cf5eb9bd861e6af7a2f182 Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 11:02:03 -0400
Subject: [PATCH 1/8] Remove operate/ section; add aliases to all new-IA
 destinations
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Delete the entire operate/ directory (162 non-draft pages, excluding
SLAM which was already migrated). Add 97 aliases across 67 destination
pages so every operate/ URL resolves to its new-IA equivalent.

Also fixes:
- 404.html card links (operate/install/setup → set-up-a-machine/overview)
- camera-model-next-steps.md include (operate/ camera links → new paths)
- 4 pre-existing stale UI labels (Component or service → Configuration
  block; Click Test → Expand TEST section)

446 body-text references to /operate/ remain across tutorials and other
pages. These redirect through aliases and are a follow-up cleanup task.

Full mapping documented in code-map/operate-removal-plan.md.
13 pages on the revisit list where the alias is accepted but unique
content needs a proper new-IA home.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 docs/build-apps/concepts/how-apps-connect.md  |    2 +
 docs/build-apps/overview.md                   |    1 +
 docs/build-modules/deploy-a-module.md         |    2 +
 docs/build-modules/manage-modules.md          |    1 +
 docs/build-modules/module-reference.md        |    3 +
 docs/build-modules/overview.md                |    4 +
 docs/build-modules/platform-apis.md           |    1 +
 docs/build-modules/use-registry-modules.md    |    2 +
 docs/build-modules/write-a-driver-module.md   |    1 +
 docs/hardware/common-components/add-a-base.md |    2 +
 .../hardware/common-components/add-a-board.md |    1 +
 .../common-components/add-a-button.md         |    1 +
 .../common-components/add-a-camera.md         |    2 +
 .../common-components/add-a-gantry.md         |    1 +
 .../common-components/add-a-generic.md        |    1 +
 .../common-components/add-a-gripper.md        |    1 +
 .../hardware/common-components/add-a-motor.md |    1 +
 .../add-a-movement-sensor.md                  |    2 +
 .../common-components/add-a-power-sensor.md   |    1 +
 .../common-components/add-a-sensor.md         |    1 +
 .../common-components/add-a-switch.md         |    1 +
 docs/hardware/common-components/add-an-arm.md |    3 +
 .../common-components/add-an-encoder.md       |    1 +
 .../add-an-input-controller.md                |    1 +
 docs/hardware/configure-hardware.md           |   11 +
 docs/hardware/multi-machine/overview.md       |    8 +
 docs/motion-planning/frame-system/overview.md |    1 +
 docs/operate/_index.md                        |   67 -
 docs/operate/control/_index.md                |   10 -
 docs/operate/control/api-keys.md              |   54 -
 docs/operate/control/headless-app.md          |  411 ----
 docs/operate/control/kiosk-app.md             |   10 -
 docs/operate/control/mobile-app.md            |  105 -
 docs/operate/control/sdks.md                  |    8 -
 docs/operate/control/viam-applications.md     |  434 -----
 docs/operate/control/voice-app.md             |   10 -
 docs/operate/control/web-app.md               |  368 ----
 docs/operate/hello-world/_index.md            |   10 -
 docs/operate/hello-world/building.md          |  513 -----
 .../hello-world/first-project/_index.md       |   89 -
 .../hello-world/first-project/part-1.md       |  206 --
 .../hello-world/first-project/part-2.md       |  107 --
 .../hello-world/first-project/part-3.md       |  582 ------
 .../hello-world/first-project/part-4.md       |  405 ----
 .../hello-world/first-project/part-5.md       |  266 ---
 .../hello-world/first-project/sim-setup.md    |   68 -
 .../hello-world/problems-viam-solves.md       |  150 --
 .../hello-world/tutorial-desk-safari.md       |  792 --------
 docs/operate/hello-world/what-is-viam.md      |  159 --
 docs/operate/install/_index.md                |   10 -
 docs/operate/install/setup-micro/_index.md    |  403 ----
 .../setup-micro/micro-troubleshooting.md      |  220 ---
 docs/operate/install/setup.md                 |  149 --
 docs/operate/modules/_index.md                |   10 -
 docs/operate/modules/advanced/_index.md       |   10 -
 docs/operate/modules/advanced/cpp-module.md   | 1688 -----------------
 docs/operate/modules/advanced/dependencies.md |  496 -----
 docs/operate/modules/advanced/logging.md      |   73 -
 .../modules/advanced/manage-modules.md        |  456 -----
 docs/operate/modules/advanced/metajson.md     |   69 -
 docs/operate/modules/advanced/micro-module.md |  122 --
 .../modules/advanced/module-configuration.md  |  497 -----
 .../operate/modules/advanced/platform-apis.md |  310 ---
 docs/operate/modules/component-apis/_index.md |    8 -
 docs/operate/modules/component-apis/arm.md    |   10 -
 docs/operate/modules/component-apis/base.md   |   10 -
 docs/operate/modules/component-apis/board.md  |   10 -
 docs/operate/modules/component-apis/button.md |   10 -
 docs/operate/modules/component-apis/camera.md |   10 -
 .../operate/modules/component-apis/encoder.md |   10 -
 docs/operate/modules/component-apis/gantry.md |   10 -
 .../operate/modules/component-apis/generic.md |   10 -
 .../operate/modules/component-apis/gripper.md |   10 -
 .../component-apis/input-controller.md        |   10 -
 docs/operate/modules/component-apis/motor.md  |   10 -
 .../modules/component-apis/movement-sensor.md |   10 -
 .../modules/component-apis/power-sensor.md    |   10 -
 docs/operate/modules/component-apis/sensor.md |   10 -
 docs/operate/modules/component-apis/servo.md  |   10 -
 docs/operate/modules/component-apis/switch.md |   10 -
 docs/operate/modules/configure-modules.md     |  291 ---
 docs/operate/modules/deploy-a-module.md       |  508 -----
 docs/operate/modules/lifecycle-of-a-module.md |   54 -
 .../modules/write-a-driver-module/_index.md   | 1062 -----------
 docs/operate/modules/write-a-logic-module.md  |  726 -------
 .../operate/modules/write-an-inline-module.md |  570 ------
 docs/operate/reference/_index.md              |    9 -
 .../reference/advanced-modules/_index.md      |   57 -
 .../advanced-modules/create-subtype.md        |  122 --
 .../custom-components-remotes.md              |   72 -
 .../advanced-modules/docker-modules.md        |   74 -
 docs/operate/reference/architecture/_index.md |  214 ---
 .../architecture/machine-to-machine-comms.md  |  129 --
 docs/operate/reference/architecture/parts.md  |  158 --
 docs/operate/reference/components/_index.md   |   11 -
 .../reference/components/arm/_index.md        |  102 -
 docs/operate/reference/components/arm/eva.md  |   50 -
 docs/operate/reference/components/arm/fake.md |   94 -
 .../components/arm/yahboom-dofbot.md          |   88 -
 .../reference/components/base/_index.md       |   98 -
 .../operate/reference/components/base/boat.md |   88 -
 .../operate/reference/components/base/fake.md |   62 -
 .../components/base/sensor-controlled.md      |  126 --
 .../components/base/two_wheeled_base.md       |   97 -
 .../reference/components/base/wheeled.md      |  168 --
 .../reference/components/board/_index.md      |  105 -
 .../reference/components/board/esp32.md       |  200 --
 .../reference/components/board/fake.md        |   87 -
 .../reference/components/button/_index.md     |   69 -
 .../reference/components/camera/_index.md     |  116 --
 .../reference/components/camera/calibrate.md  |  118 --
 .../components/camera/esp32-camera.md         |  205 --
 .../components/camera/fake-micro-server.md    |   70 -
 .../reference/components/camera/fake.md       |   83 -
 .../reference/components/camera/ffmpeg.md     |  126 --
 .../reference/components/camera/image-file.md |   98 -
 .../reference/components/camera/transform.md  |  333 ----
 .../reference/components/camera/webcam.md     |  323 ----
 .../reference/components/component/_index.md  |   89 -
 .../reference/components/component/board1.md  |  105 -
 .../reference/components/component/model1.md  |  147 --
 .../reference/components/encoder/_index.md    |   99 -
 .../reference/components/encoder/arduino.md   |   70 -
 .../reference/components/encoder/fake.md      |   76 -
 .../encoder/incremental-micro-rdk.md          |  100 -
 .../components/encoder/incremental.md         |  108 --
 .../components/encoder/single-micro-rdk.md    |   78 -
 .../reference/components/encoder/single.md    |   77 -
 .../reference/components/gantry/_index.md     |   89 -
 .../reference/components/gantry/fake.md       |   61 -
 .../reference/components/gantry/multi-axis.md |  224 ---
 .../components/gantry/single-axis.md          |   87 -
 .../reference/components/generic/_index.md    |   98 -
 .../reference/components/generic/fake.md      |   58 -
 .../reference/components/gripper/_index.md    |   81 -
 .../reference/components/gripper/fake.md      |   61 -
 .../components/input-controller/_index.md     |   84 -
 .../components/input-controller/fake.md       |   82 -
 .../components/input-controller/gamepad.md    |   93 -
 .../components/input-controller/gpio.md       |  230 ---
 .../components/input-controller/mux.md        |  132 --
 .../components/input-controller/webgamepad.md |   79 -
 .../reference/components/motor/_index.md      |   80 -
 .../reference/components/motor/dmc4000.md     |  285 ---
 .../components/motor/encoded-motor.md         |  205 --
 .../reference/components/motor/fake.md        |  129 --
 .../components/motor/gpio-micro-rdk.md        |  170 --
 .../reference/components/motor/gpio.md        |  217 ---
 .../reference/components/motor/gpiostepper.md |  149 --
 .../components/movement-sensor/_index.md      |   97 -
 .../accel-adxl345-micro-rdk.md                |  147 --
 .../components/movement-sensor/fake.md        |   87 -
 .../movement-sensor/gyro-mpu6050-micro-rdk.md |  147 --
 .../components/movement-sensor/merged.md      |  130 --
 .../movement-sensor/set-up-base-station.md    |  217 ---
 .../movement-sensor/wheeled-odometry.md       |  134 --
 .../components/power-sensor/_index.md         |   79 -
 .../reference/components/power-sensor/fake.md |   60 -
 .../reference/components/sensor/_index.md     |   88 -
 .../reference/components/sensor/fake.md       |   68 -
 .../components/sensor/ultrasonic-micro-rdk.md |  126 --
 .../reference/components/servo/_index.md      |   80 -
 .../reference/components/servo/fake.md        |   61 -
 .../components/servo/gpio-micro-rdk.md        |  159 --
 .../reference/components/servo/gpio.md        |  120 --
 .../reference/components/switch/_index.md     |   73 -
 .../reference/components/switch/fake.md       |  101 -
 docs/operate/reference/controls-package.md    |  667 -------
 docs/operate/reference/glossary.md            |    8 -
 .../reference/kinematic-chain-config.md       |  319 ----
 docs/operate/reference/prepare/_index.md      |   10 -
 .../reference/prepare/beaglebone-setup.md     |   97 -
 .../operate/reference/prepare/board1-setup.md |   74 -
 .../prepare/jetson-agx-orin-setup.md          |  158 --
 .../reference/prepare/jetson-nano-setup.md    |  124 --
 .../reference/prepare/odroid-c4-setup.md      |   79 -
 .../reference/prepare/orange-pi-3-lts.md      |   99 -
 .../reference/prepare/orange-pi-zero2.md      |   92 -
 docs/operate/reference/prepare/pumpkin.md     |  264 ---
 docs/operate/reference/prepare/rpi-setup.md   |  193 --
 docs/operate/reference/prepare/sk-tda4vm.md   |  121 --
 docs/operate/reference/services/_index.md     |   11 -
 .../reference/services/base-rc/_index.md      |  134 --
 .../reference/services/discovery/_index.md    |   69 -
 .../reference/services/frame-system/_index.md |  212 ---
 .../reference/services/generic/_index.md      |   58 -
 .../reference/services/generic/fake.md        |   43 -
 .../reference/services/motion/_index.md       |  187 --
 .../reference/services/motion/algorithms.md   |   62 -
 .../reference/services/motion/constraints.md  |  139 --
 .../reference/services/navigation/_index.md   |  387 ----
 .../operate/reference/services/slam/_index.md |   75 -
 .../services/slam/cartographer/_index.md      |  474 -----
 .../services/slam/cloudslam/_index.md         |  442 -----
 .../services/slam/orbslamv3/_index.md         |  377 ----
 docs/operate/reference/sessions.md            |    8 -
 docs/operate/reference/slam-background.md     |  280 ---
 .../reference/viam-micro-server/_index.md     |   54 -
 docs/operate/reference/viam-server/_index.md  |  472 -----
 .../reference/viam-server/debug-endpoints.md  |   94 -
 .../viam-server/manage-viam-server.md         |  382 ----
 docs/operate/reference/wifi-credentials.md    |   45 -
 docs/organization/access.md                   |    1 +
 docs/reference/_index.md                      |    2 +
 docs/reference/apis/components/_index.md      |    1 +
 docs/reference/apis/components/arm.md         |    1 +
 docs/reference/apis/components/base.md        |    1 +
 docs/reference/apis/components/board.md       |    1 +
 docs/reference/apis/components/button.md      |    1 +
 docs/reference/apis/components/camera.md      |    1 +
 docs/reference/apis/components/encoder.md     |    1 +
 docs/reference/apis/components/gantry.md      |    1 +
 docs/reference/apis/components/generic.md     |    1 +
 docs/reference/apis/components/gripper.md     |    1 +
 .../apis/components/input-controller.md       |    1 +
 docs/reference/apis/components/motor.md       |    1 +
 .../apis/components/movement-sensor.md        |    1 +
 .../reference/apis/components/power-sensor.md |    1 +
 docs/reference/apis/components/sensor.md      |    1 +
 docs/reference/apis/components/servo.md       |    1 +
 docs/reference/apis/components/switch.md      |    1 +
 docs/reference/components/_index.md           |    2 +
 .../base/micro-rdk/two_wheeled_base.md        |    1 +
 .../components/board/micro-rdk/esp32.md       |    1 +
 .../camera/micro-rdk/esp32-camera.md          |    1 +
 .../components/camera/micro-rdk/fake.md       |    1 +
 docs/reference/device-setup/_index.md         |    2 +
 docs/reference/device-setup/rpi-setup.md      |    1 +
 .../device-setup/setup-micro/_index.md        |    1 +
 .../device-setup/setup-micro/micro-module.md  |    1 +
 .../setup-micro/micro-troubleshooting.md      |    1 +
 docs/reference/glossary/index.md              |    1 +
 docs/reference/glossary/vision-service.md     |    2 +-
 docs/reference/sdks/_index.md                 |    1 +
 docs/reference/services/_index.md             |    2 +
 docs/reference/services/motion/_index.md      |   31 +-
 docs/try/_index.md                            |    2 +
 docs/try/gazebo-setup.md                      |    1 +
 docs/try/part-1.md                            |    3 +-
 docs/try/part-2.md                            |    1 +
 docs/try/part-3.md                            |    1 +
 docs/try/part-4.md                            |    3 +-
 docs/try/part-5.md                            |    1 +
 docs/what-is-viam/_index.md                   |    1 +
 layouts/404.html                              |    4 +-
 .../components/camera-model-next-steps.md     |    4 +-
 246 files changed, 125 insertions(+), 28417 deletions(-)
 delete mode 100644 docs/operate/_index.md
 delete mode 100644 docs/operate/control/_index.md
 delete mode 100644 docs/operate/control/api-keys.md
 delete mode 100644 docs/operate/control/headless-app.md
 delete mode 100644 docs/operate/control/kiosk-app.md
 delete mode 100644 docs/operate/control/mobile-app.md
 delete mode 100644 docs/operate/control/sdks.md
 delete mode 100644 docs/operate/control/viam-applications.md
 delete mode 100644 docs/operate/control/voice-app.md
 delete mode 100644 docs/operate/control/web-app.md
 delete mode 100644 docs/operate/hello-world/_index.md
 delete mode 100644 docs/operate/hello-world/building.md
 delete mode 100644 docs/operate/hello-world/first-project/_index.md
 delete mode 100644 docs/operate/hello-world/first-project/part-1.md
 delete mode 100644 docs/operate/hello-world/first-project/part-2.md
 delete mode 100644 docs/operate/hello-world/first-project/part-3.md
 delete mode 100644 docs/operate/hello-world/first-project/part-4.md
 delete mode 100644 docs/operate/hello-world/first-project/part-5.md
 delete mode 100644 docs/operate/hello-world/first-project/sim-setup.md
 delete mode 100644 docs/operate/hello-world/problems-viam-solves.md
 delete mode 100644 docs/operate/hello-world/tutorial-desk-safari.md
 delete mode 100644 docs/operate/hello-world/what-is-viam.md
 delete mode 100644 docs/operate/install/_index.md
 delete mode 100644 docs/operate/install/setup-micro/_index.md
 delete mode 100644 docs/operate/install/setup-micro/micro-troubleshooting.md
 delete mode 100644 docs/operate/install/setup.md
 delete mode 100644 docs/operate/modules/_index.md
 delete mode 100644 docs/operate/modules/advanced/_index.md
 delete mode 100644 docs/operate/modules/advanced/cpp-module.md
 delete mode 100644 docs/operate/modules/advanced/dependencies.md
 delete mode 100644 docs/operate/modules/advanced/logging.md
 delete mode 100644 docs/operate/modules/advanced/manage-modules.md
 delete mode 100644 docs/operate/modules/advanced/metajson.md
 delete mode 100644 docs/operate/modules/advanced/micro-module.md
 delete mode 100644 docs/operate/modules/advanced/module-configuration.md
 delete mode 100644 docs/operate/modules/advanced/platform-apis.md
 delete mode 100644 docs/operate/modules/component-apis/_index.md
 delete mode 100644 docs/operate/modules/component-apis/arm.md
 delete mode 100644 docs/operate/modules/component-apis/base.md
 delete mode 100644 docs/operate/modules/component-apis/board.md
 delete mode 100644 docs/operate/modules/component-apis/button.md
 delete mode 100644 docs/operate/modules/component-apis/camera.md
 delete mode 100644 docs/operate/modules/component-apis/encoder.md
 delete mode 100644 docs/operate/modules/component-apis/gantry.md
 delete mode 100644 docs/operate/modules/component-apis/generic.md
 delete mode 100644 docs/operate/modules/component-apis/gripper.md
 delete mode 100644 docs/operate/modules/component-apis/input-controller.md
 delete mode 100644 docs/operate/modules/component-apis/motor.md
 delete mode 100644 docs/operate/modules/component-apis/movement-sensor.md
 delete mode 100644 docs/operate/modules/component-apis/power-sensor.md
 delete mode 100644 docs/operate/modules/component-apis/sensor.md
 delete mode 100644 docs/operate/modules/component-apis/servo.md
 delete mode 100644 docs/operate/modules/component-apis/switch.md
 delete mode 100644 docs/operate/modules/configure-modules.md
 delete mode 100644 docs/operate/modules/deploy-a-module.md
 delete mode 100644 docs/operate/modules/lifecycle-of-a-module.md
 delete mode 100644 docs/operate/modules/write-a-driver-module/_index.md
 delete mode 100644 docs/operate/modules/write-a-logic-module.md
 delete mode 100644 docs/operate/modules/write-an-inline-module.md
 delete mode 100644 docs/operate/reference/_index.md
 delete mode 100644 docs/operate/reference/advanced-modules/_index.md
 delete mode 100644 docs/operate/reference/advanced-modules/create-subtype.md
 delete mode 100644 docs/operate/reference/advanced-modules/custom-components-remotes.md
 delete mode 100644 docs/operate/reference/advanced-modules/docker-modules.md
 delete mode 100644 docs/operate/reference/architecture/_index.md
 delete mode 100644 docs/operate/reference/architecture/machine-to-machine-comms.md
 delete mode 100644 docs/operate/reference/architecture/parts.md
 delete mode 100644 docs/operate/reference/components/_index.md
 delete mode 100644 docs/operate/reference/components/arm/_index.md
 delete mode 100644 docs/operate/reference/components/arm/eva.md
 delete mode 100644 docs/operate/reference/components/arm/fake.md
 delete mode 100644 docs/operate/reference/components/arm/yahboom-dofbot.md
 delete mode 100644 docs/operate/reference/components/base/_index.md
 delete mode 100644 docs/operate/reference/components/base/boat.md
 delete mode 100644 docs/operate/reference/components/base/fake.md
 delete mode 100644 docs/operate/reference/components/base/sensor-controlled.md
 delete mode 100644 docs/operate/reference/components/base/two_wheeled_base.md
 delete mode 100644 docs/operate/reference/components/base/wheeled.md
 delete mode 100644 docs/operate/reference/components/board/_index.md
 delete mode 100644 docs/operate/reference/components/board/esp32.md
 delete mode 100644 docs/operate/reference/components/board/fake.md
 delete mode 100644 docs/operate/reference/components/button/_index.md
 delete mode 100644 docs/operate/reference/components/camera/_index.md
 delete mode 100644 docs/operate/reference/components/camera/calibrate.md
 delete mode 100644 docs/operate/reference/components/camera/esp32-camera.md
 delete mode 100644 docs/operate/reference/components/camera/fake-micro-server.md
 delete mode 100644 docs/operate/reference/components/camera/fake.md
 delete mode 100644 docs/operate/reference/components/camera/ffmpeg.md
 delete mode 100644 docs/operate/reference/components/camera/image-file.md
 delete mode 100644 docs/operate/reference/components/camera/transform.md
 delete mode 100644 docs/operate/reference/components/camera/webcam.md
 delete mode 100644 docs/operate/reference/components/component/_index.md
 delete mode 100644 docs/operate/reference/components/component/board1.md
 delete mode 100644 docs/operate/reference/components/component/model1.md
 delete mode 100644 docs/operate/reference/components/encoder/_index.md
 delete mode 100644 docs/operate/reference/components/encoder/arduino.md
 delete mode 100644 docs/operate/reference/components/encoder/fake.md
 delete mode 100644 docs/operate/reference/components/encoder/incremental-micro-rdk.md
 delete mode 100644 docs/operate/reference/components/encoder/incremental.md
 delete mode 100644 docs/operate/reference/components/encoder/single-micro-rdk.md
 delete mode 100644 docs/operate/reference/components/encoder/single.md
 delete mode 100644 docs/operate/reference/components/gantry/_index.md
 delete mode 100644 docs/operate/reference/components/gantry/fake.md
 delete mode 100644 docs/operate/reference/components/gantry/multi-axis.md
 delete mode 100644 docs/operate/reference/components/gantry/single-axis.md
 delete mode 100644 docs/operate/reference/components/generic/_index.md
 delete mode 100644 docs/operate/reference/components/generic/fake.md
 delete mode 100644 docs/operate/reference/components/gripper/_index.md
 delete mode 100644 docs/operate/reference/components/gripper/fake.md
 delete mode 100644 docs/operate/reference/components/input-controller/_index.md
 delete mode 100644 docs/operate/reference/components/input-controller/fake.md
 delete mode 100644 docs/operate/reference/components/input-controller/gamepad.md
 delete mode 100644 docs/operate/reference/components/input-controller/gpio.md
 delete mode 100644 docs/operate/reference/components/input-controller/mux.md
 delete mode 100644 docs/operate/reference/components/input-controller/webgamepad.md
 delete mode 100644 docs/operate/reference/components/motor/_index.md
 delete mode 100644 docs/operate/reference/components/motor/dmc4000.md
 delete mode 100644 docs/operate/reference/components/motor/encoded-motor.md
 delete mode 100644 docs/operate/reference/components/motor/fake.md
 delete mode 100644 docs/operate/reference/components/motor/gpio-micro-rdk.md
 delete mode 100644 docs/operate/reference/components/motor/gpio.md
 delete mode 100644 docs/operate/reference/components/motor/gpiostepper.md
 delete mode 100644 docs/operate/reference/components/movement-sensor/_index.md
 delete mode 100644 docs/operate/reference/components/movement-sensor/accel-adxl345-micro-rdk.md
 delete mode 100644 docs/operate/reference/components/movement-sensor/fake.md
 delete mode 100644 docs/operate/reference/components/movement-sensor/gyro-mpu6050-micro-rdk.md
 delete mode 100644 docs/operate/reference/components/movement-sensor/merged.md
 delete mode 100644 docs/operate/reference/components/movement-sensor/set-up-base-station.md
 delete mode 100644 docs/operate/reference/components/movement-sensor/wheeled-odometry.md
 delete mode 100644 docs/operate/reference/components/power-sensor/_index.md
 delete mode 100644 docs/operate/reference/components/power-sensor/fake.md
 delete mode 100644 docs/operate/reference/components/sensor/_index.md
 delete mode 100644 docs/operate/reference/components/sensor/fake.md
 delete mode 100644 docs/operate/reference/components/sensor/ultrasonic-micro-rdk.md
 delete mode 100644 docs/operate/reference/components/servo/_index.md
 delete mode 100644 docs/operate/reference/components/servo/fake.md
 delete mode 100644 docs/operate/reference/components/servo/gpio-micro-rdk.md
 delete mode 100644 docs/operate/reference/components/servo/gpio.md
 delete mode 100644 docs/operate/reference/components/switch/_index.md
 delete mode 100644 docs/operate/reference/components/switch/fake.md
 delete mode 100644 docs/operate/reference/controls-package.md
 delete mode 100644 docs/operate/reference/glossary.md
 delete mode 100644 docs/operate/reference/kinematic-chain-config.md
 delete mode 100644 docs/operate/reference/prepare/_index.md
 delete mode 100644 docs/operate/reference/prepare/beaglebone-setup.md
 delete mode 100644 docs/operate/reference/prepare/board1-setup.md
 delete mode 100644 docs/operate/reference/prepare/jetson-agx-orin-setup.md
 delete mode 100644 docs/operate/reference/prepare/jetson-nano-setup.md
 delete mode 100644 docs/operate/reference/prepare/odroid-c4-setup.md
 delete mode 100644 docs/operate/reference/prepare/orange-pi-3-lts.md
 delete mode 100644 docs/operate/reference/prepare/orange-pi-zero2.md
 delete mode 100644 docs/operate/reference/prepare/pumpkin.md
 delete mode 100644 docs/operate/reference/prepare/rpi-setup.md
 delete mode 100644 docs/operate/reference/prepare/sk-tda4vm.md
 delete mode 100644 docs/operate/reference/services/_index.md
 delete mode 100644 docs/operate/reference/services/base-rc/_index.md
 delete mode 100644 docs/operate/reference/services/discovery/_index.md
 delete mode 100644 docs/operate/reference/services/frame-system/_index.md
 delete mode 100644 docs/operate/reference/services/generic/_index.md
 delete mode 100644 docs/operate/reference/services/generic/fake.md
 delete mode 100644 docs/operate/reference/services/motion/_index.md
 delete mode 100644 docs/operate/reference/services/motion/algorithms.md
 delete mode 100644 docs/operate/reference/services/motion/constraints.md
 delete mode 100644 docs/operate/reference/services/navigation/_index.md
 delete mode 100644 docs/operate/reference/services/slam/_index.md
 delete mode 100644 docs/operate/reference/services/slam/cartographer/_index.md
 delete mode 100644 docs/operate/reference/services/slam/cloudslam/_index.md
 delete mode 100644 docs/operate/reference/services/slam/orbslamv3/_index.md
 delete mode 100644 docs/operate/reference/sessions.md
 delete mode 100644 docs/operate/reference/slam-background.md
 delete mode 100644 docs/operate/reference/viam-micro-server/_index.md
 delete mode 100644 docs/operate/reference/viam-server/_index.md
 delete mode 100644 docs/operate/reference/viam-server/debug-endpoints.md
 delete mode 100644 docs/operate/reference/viam-server/manage-viam-server.md
 delete mode 100644 docs/operate/reference/wifi-credentials.md

diff --git a/docs/build-apps/concepts/how-apps-connect.md b/docs/build-apps/concepts/how-apps-connect.md
index 21340d39eb..4e36a1c719 100644
--- a/docs/build-apps/concepts/how-apps-connect.md
+++ b/docs/build-apps/concepts/how-apps-connect.md
@@ -6,6 +6,8 @@ layout: "docs"
 type: "docs"
 description: "The transport paths the SDK uses, the session safety mechanism, and what the SDK reconnects automatically."
 date: "2026-04-10"
+aliases:
+  - /operate/reference/sessions/
 ---
 
 A Viam client application needs to reach a machine that may be on a different network, behind a NAT, or both. This page describes the transport paths the SDK uses, the session safety mechanism, and how the SDK reconnects when the network drops.
diff --git a/docs/build-apps/overview.md b/docs/build-apps/overview.md
index f0349089ed..2b21293dd2 100644
--- a/docs/build-apps/overview.md
+++ b/docs/build-apps/overview.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Build software that uses a Viam SDK to talk to your machines and the Viam cloud, from web dashboards to long-running backend services."
 date: "2026-04-10"
 aliases:
+  - /operate/control/
   - /operate/control/headless-app/
   - /product-overviews/sdk-as-client/
   - /program/sdk-as-client/
diff --git a/docs/build-modules/deploy-a-module.md b/docs/build-modules/deploy-a-module.md
index 0aa5c7c3b3..c4f73ef51c 100644
--- a/docs/build-modules/deploy-a-module.md
+++ b/docs/build-modules/deploy-a-module.md
@@ -7,6 +7,8 @@ type: "docs"
 description: "Package, upload, and distribute a module through the Viam registry."
 date: "2025-01-30"
 aliases:
+  - /operate/modules/deploy-a-module/
+  - /operate/reference/advanced-modules/docker-modules/
   - /build/development/deploy-a-module/
   - /development/deploy-a-module/
   - /extend/modular-resources/upload/
diff --git a/docs/build-modules/manage-modules.md b/docs/build-modules/manage-modules.md
index d13e9d127a..5f3efbdf00 100644
--- a/docs/build-modules/manage-modules.md
+++ b/docs/build-modules/manage-modules.md
@@ -8,6 +8,7 @@ icon: true
 tags: ["modular resources", "components", "services", "registry"]
 description: "Update or delete your existing modules, or change their privacy settings."
 aliases:
+  - /operate/modules/advanced/manage-modules/
   - /use-cases/deploy-code/
   - /use-cases/manage-modules/
   - /how-tos/manage-modules/
diff --git a/docs/build-modules/module-reference.md b/docs/build-modules/module-reference.md
index 89d6867f57..c2014371cf 100644
--- a/docs/build-modules/module-reference.md
+++ b/docs/build-modules/module-reference.md
@@ -7,6 +7,9 @@ type: "docs"
 description: "Reference for module developers: lifecycle, interfaces, meta.json schema, CLI commands, environment variables, and registry rules."
 date: "2025-03-05"
 aliases:
+  - /operate/modules/advanced/logging/
+  - /operate/modules/advanced/metajson/
+  - /operate/modules/advanced/module-configuration/
   - /development/module-reference/
   - /operate/modules/lifecycle-module/
   - /operate/modules/lifecycle-of-a-module/
diff --git a/docs/build-modules/overview.md b/docs/build-modules/overview.md
index ca9b4c71fe..9914978a93 100644
--- a/docs/build-modules/overview.md
+++ b/docs/build-modules/overview.md
@@ -6,6 +6,10 @@ layout: "docs"
 type: "docs"
 description: "Understand the two kinds of modules and how to extend your machine with custom hardware drivers and application logic."
 aliases:
+  - /operate/modules/
+  - /operate/modules/advanced/
+  - /operate/reference/advanced-modules/
+  - /operate/reference/advanced-modules/create-subtype/
   - /build-modules/from-hardware-to-logic/
 ---
 
diff --git a/docs/build-modules/platform-apis.md b/docs/build-modules/platform-apis.md
index 76a04e5643..a26f723f34 100644
--- a/docs/build-modules/platform-apis.md
+++ b/docs/build-modules/platform-apis.md
@@ -6,6 +6,7 @@ layout: "docs"
 type: "docs"
 description: "Write your validate and reconfigure functions to handle dependencies in your custom modular resource."
 aliases:
+  - /operate/modules/advanced/platform-apis/
 date: "2025-11-05"
 ---
 
diff --git a/docs/build-modules/use-registry-modules.md b/docs/build-modules/use-registry-modules.md
index 5555a8bb84..fe5399db85 100644
--- a/docs/build-modules/use-registry-modules.md
+++ b/docs/build-modules/use-registry-modules.md
@@ -6,6 +6,8 @@ layout: "docs"
 type: "docs"
 description: "Before writing a module, check whether one already exists. The registry has more than hardware drivers."
 date: "2026-04-17"
+aliases:
+  - /registry/
 ---
 
 Before you write a module, check whether one already exists. The Viam registry contains more than hardware drivers. Many software capabilities you might want to build are already published as modules you can configure and use directly.
diff --git a/docs/build-modules/write-a-driver-module.md b/docs/build-modules/write-a-driver-module.md
index 91d8004460..7eaf692b56 100644
--- a/docs/build-modules/write-a-driver-module.md
+++ b/docs/build-modules/write-a-driver-module.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Build a module that implements a resource API and runs as a separate process."
 date: "2025-01-30"
 aliases:
+  - /operate/modules/write-a-driver-module/
   - /build/development/write-a-module/
   - /development/write-a-module/
   - /development/write-a-driver-module/
diff --git a/docs/hardware/common-components/add-a-base.md b/docs/hardware/common-components/add-a-base.md
index 084e84c690..3793edb89b 100644
--- a/docs/hardware/common-components/add-a-base.md
+++ b/docs/hardware/common-components/add-a-base.md
@@ -7,6 +7,8 @@ type: "docs"
 description: "Add and configure a base to drive a mobile robot with movement commands."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/base/
+  - /operate/reference/components/base/boat/
   - /hardware-components/add-a-base/
 ---
 
diff --git a/docs/hardware/common-components/add-a-board.md b/docs/hardware/common-components/add-a-board.md
index f676b2dd4c..33c48f3c2f 100644
--- a/docs/hardware/common-components/add-a-board.md
+++ b/docs/hardware/common-components/add-a-board.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a board component to expose GPIO pins, analog readers, and digital interrupts."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/board/
   - /hardware-components/add-a-board/
 ---
 
diff --git a/docs/hardware/common-components/add-a-button.md b/docs/hardware/common-components/add-a-button.md
index 73f2930202..41996c815e 100644
--- a/docs/hardware/common-components/add-a-button.md
+++ b/docs/hardware/common-components/add-a-button.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a button component to detect presses from a physical button."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/button/
   - /hardware-components/add-a-button/
 ---
 
diff --git a/docs/hardware/common-components/add-a-camera.md b/docs/hardware/common-components/add-a-camera.md
index cb3d39bb79..4b6dfb8c7e 100644
--- a/docs/hardware/common-components/add-a-camera.md
+++ b/docs/hardware/common-components/add-a-camera.md
@@ -7,6 +7,8 @@ type: "docs"
 description: "Add and configure a camera component, verify the feed, and capture an image programmatically."
 date: "2025-01-30"
 aliases:
+  - /operate/reference/components/camera/
+  - /operate/reference/components/camera/calibrate/
   - /build/foundation/add-a-camera/
   - /foundation/add-a-camera/
   - /hardware-components/add-a-camera/
diff --git a/docs/hardware/common-components/add-a-gantry.md b/docs/hardware/common-components/add-a-gantry.md
index deafcaa0ab..4b757960ae 100644
--- a/docs/hardware/common-components/add-a-gantry.md
+++ b/docs/hardware/common-components/add-a-gantry.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a gantry component for precise linear positioning along one or more axes."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/gantry/
   - /hardware-components/add-a-gantry/
 ---
 
diff --git a/docs/hardware/common-components/add-a-generic.md b/docs/hardware/common-components/add-a-generic.md
index 4273ecf4c2..ad2c95bc6b 100644
--- a/docs/hardware/common-components/add-a-generic.md
+++ b/docs/hardware/common-components/add-a-generic.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a generic component for hardware that doesn't fit any other component type."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/generic/
   - /hardware-components/add-a-generic/
 ---
 
diff --git a/docs/hardware/common-components/add-a-gripper.md b/docs/hardware/common-components/add-a-gripper.md
index a212ac17b7..21144699fb 100644
--- a/docs/hardware/common-components/add-a-gripper.md
+++ b/docs/hardware/common-components/add-a-gripper.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a gripper component to open, close, and grasp objects."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/gripper/
   - /hardware-components/add-a-gripper/
 ---
 
diff --git a/docs/hardware/common-components/add-a-motor.md b/docs/hardware/common-components/add-a-motor.md
index 4e1c736a50..1ee617340f 100644
--- a/docs/hardware/common-components/add-a-motor.md
+++ b/docs/hardware/common-components/add-a-motor.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a motor component and test it from the Viam app."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/motor/
   - /hardware-components/add-a-motor/
 ---
 
diff --git a/docs/hardware/common-components/add-a-movement-sensor.md b/docs/hardware/common-components/add-a-movement-sensor.md
index 3d0867f3d0..5a930caee0 100644
--- a/docs/hardware/common-components/add-a-movement-sensor.md
+++ b/docs/hardware/common-components/add-a-movement-sensor.md
@@ -7,6 +7,8 @@ type: "docs"
 description: "Add and configure a movement sensor like a GPS, IMU, or odometry source."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/movement-sensor/
+  - /operate/reference/components/movement-sensor/set-up-base-station/
   - /hardware-components/add-a-movement-sensor/
 ---
 
diff --git a/docs/hardware/common-components/add-a-power-sensor.md b/docs/hardware/common-components/add-a-power-sensor.md
index df1219b740..ae1e090933 100644
--- a/docs/hardware/common-components/add-a-power-sensor.md
+++ b/docs/hardware/common-components/add-a-power-sensor.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a power sensor to monitor voltage, current, and power consumption."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/power-sensor/
   - /hardware-components/add-a-power-sensor/
 ---
 
diff --git a/docs/hardware/common-components/add-a-sensor.md b/docs/hardware/common-components/add-a-sensor.md
index 75c64af9f2..fcc5c1983f 100644
--- a/docs/hardware/common-components/add-a-sensor.md
+++ b/docs/hardware/common-components/add-a-sensor.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a sensor to read environmental data like temperature, humidity, or distance."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/sensor/
   - /hardware-components/add-a-sensor/
 ---
 
diff --git a/docs/hardware/common-components/add-a-switch.md b/docs/hardware/common-components/add-a-switch.md
index 04ecddb97d..86578dbb5b 100644
--- a/docs/hardware/common-components/add-a-switch.md
+++ b/docs/hardware/common-components/add-a-switch.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a switch component to read and set the position of a multi-position switch."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/switch/
   - /hardware-components/add-a-switch/
 ---
 
diff --git a/docs/hardware/common-components/add-an-arm.md b/docs/hardware/common-components/add-an-arm.md
index 2ece18425e..a3a29ccc1c 100644
--- a/docs/hardware/common-components/add-an-arm.md
+++ b/docs/hardware/common-components/add-an-arm.md
@@ -7,6 +7,9 @@ type: "docs"
 description: "Add and configure a robotic arm, verify joint motion, and test end-effector positioning."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/arm/
+  - /operate/reference/components/arm/eva/
+  - /operate/reference/components/arm/yahboom-dofbot/
   - /hardware-components/add-an-arm/
 ---
 
diff --git a/docs/hardware/common-components/add-an-encoder.md b/docs/hardware/common-components/add-an-encoder.md
index d7e37a1e9f..d357cde70a 100644
--- a/docs/hardware/common-components/add-an-encoder.md
+++ b/docs/hardware/common-components/add-an-encoder.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure an encoder to track motor position and direction."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/encoder/
   - /hardware-components/add-an-encoder/
 ---
 
diff --git a/docs/hardware/common-components/add-an-input-controller.md b/docs/hardware/common-components/add-an-input-controller.md
index ddc874763f..fa70452901 100644
--- a/docs/hardware/common-components/add-an-input-controller.md
+++ b/docs/hardware/common-components/add-an-input-controller.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Add and configure a gamepad, joystick, or other input device for manual machine control."
 date: "2025-03-07"
 aliases:
+  - /operate/reference/components/input-controller/
   - /hardware-components/add-an-input-controller/
 ---
 
diff --git a/docs/hardware/configure-hardware.md b/docs/hardware/configure-hardware.md
index e3c8bf8742..b3bbb8178a 100644
--- a/docs/hardware/configure-hardware.md
+++ b/docs/hardware/configure-hardware.md
@@ -7,6 +7,17 @@ type: "docs"
 description: "Understand how Viam represents hardware, add components to your machine, and configure them."
 date: "2025-03-07"
 aliases:
+  - /program/extend/modular-resources/configure/
+  - /extend/modular-resources/configure/
+  - /modular-resources/configure/
+  - /registry/configure/
+  - /registry/modular-resources/
+  - /configure/
+  - /manage/configuration/
+  - /build/configure/
+  - /registry/program/extend/modular-resources/configure/
+  - /how-tos/use-cases/configure/
+  - /use-cases/configure/
   - /hardware-components/add-a-component/
   - /hardware/add-a-component/
   - /operate/modules/configure-modules/
diff --git a/docs/hardware/multi-machine/overview.md b/docs/hardware/multi-machine/overview.md
index 6a98116615..d097d093c6 100644
--- a/docs/hardware/multi-machine/overview.md
+++ b/docs/hardware/multi-machine/overview.md
@@ -7,6 +7,14 @@ type: "docs"
 description: "Connect multiple computers so one machine can access another's components and services."
 date: "2026-04-16"
 aliases:
+  - /manage/parts-and-remotes/
+  - /build/configure/parts-and-remotes/
+  - /configure/parts/
+  - /build/configure/parts/
+  - /architecture/parts/
+  - /operate/reference/advanced-modules/custom-components-remotes/
+  - /operate/reference/architecture/
+  - /operate/reference/architecture/machine-to-machine-comms/
   - /operate/reference/architecture/parts/
 ---
 
diff --git a/docs/motion-planning/frame-system/overview.md b/docs/motion-planning/frame-system/overview.md
index 821cc5d8cc..913f09a2aa 100644
--- a/docs/motion-planning/frame-system/overview.md
+++ b/docs/motion-planning/frame-system/overview.md
@@ -6,6 +6,7 @@ layout: "docs"
 type: "docs"
 description: "Build a unified coordinate tree so all components agree on where things are in physical space."
 aliases:
+  - /operate/reference/kinematic-chain-config/
   - /work-cell-layout/define-your-frame-system/
   - /build/work-cell-layout/define-your-frame-system/
   - /operate/mobility/move-arm/frame-how-to/
diff --git a/docs/operate/_index.md b/docs/operate/_index.md
deleted file mode 100644
index 358d33009e..0000000000
--- a/docs/operate/_index.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-linkTitle: "Build and Integrate"
-title: "Build and Integrate"
-weight: 150
-layout: "docs"
-toc_hide: true
-type: "docs"
-no_list: true
-noedit: true
-open_on_desktop: true
-overview: true
-description: "Install Viam on any device and integrate your hardware. Then you can control your device and attached physical hardware securely from anywhere in the world."
-notoc: true
-aliases:
-  - /build/
-  - /operate/mobility/use-input-to-act/
----
-
-To get started, install Viam on any device and integrate your hardware. Then you can control your device and any attached physical hardware securely from anywhere in the world.
-
-<!-- Need to use upside down logic because using Subsequent-sibling combinator -->
-<div class="img-overlay-wrap aligncenter">
-  <img src="../platform/platform-all.svg" alt="Platform diagram" id="fleet-platform-all" class="aligncenter overview" style="width:800px;height:auto" >
-  <img src="../platform/platform-build-connect.svg" alt="Platform diagram with connect elements highlighted" class="aligncenter overlay" id="build-platform-connect" style="width:800px;height:auto" loading="lazy" >
-  <img src="../platform/platform-build-apps.svg" alt="Platform diagram with apps element highlighted" class="aligncenter overlay" id="build-platform-apps" style="width:800px;height:auto" loading="lazy" >
-  <img src="../platform/platform-build-motion.svg" alt="Platform diagram with motion elements highlighted" class="aligncenter overlay" id="build-platform-motion" style="width:800px;height:auto" loading="lazy" >
-</div>
-
-<div class="hoveraction">
-
-{{< how-to-expand "Learn Viam & Installation" "4" "BEGINNER-FRIENDLY" "" "build-platform-connect" >}}
-{{< cards >}}
-{{% card link="/operate/hello-world/what-is-viam/" noimage="true" %}}
-{{% card link="/operate/hello-world/tutorial-desk-safari/" noimage="true" %}}
-{{% card link="/operate/install/setup/" noimage="true" %}}
-{{% card link="/operate/hello-world/building/" noimage="true" %}}
-
-{{< /cards >}}
-{{< /how-to-expand >}}
-
-{{< how-to-expand "Modules" "3" "BEGINNER-FRIENDLY" "" "build-platform-connect" >}}
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/modules/write-a-driver-module/" noimage="true" %}}
-{{% card link="/operate/modules/write-a-logic-module/" noimage="true" %}}
-{{< /cards >}}
-{{< /how-to-expand >}}
-
-{{< how-to-expand "Build apps" "4" "BEGINNER-FRIENDLY" "" "build-platform-apps" >}}
-{{< cards >}}
-{{% card link="/operate/control/viam-applications/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/operate/control/mobile-app/" noimage="true" %}}
-{{% card link="/operate/control/headless-app/" noimage="true" %}}
-{{< /cards >}}
-{{< /how-to-expand >}}
-
-{{< how-to-expand "Intelligent actuation and motion planning" "4" "INTERMEDIATE" "" "build-platform-motion" >}}
-{{< cards >}}
-{{% card link="/motion-planning/" noimage="true" %}}
-{{% card link="/motion-planning/move-an-arm/move-to-pose/" noimage="true" %}}
-{{% card link="/navigation/how-to/drive-a-base/" noimage="true" %}}
-{{% card link="/motion-planning/move-gantry/" noimage="true" %}}
-{{< /cards >}}
-{{< /how-to-expand >}}
-
-</div>
diff --git a/docs/operate/control/_index.md b/docs/operate/control/_index.md
deleted file mode 100644
index 58f211c015..0000000000
--- a/docs/operate/control/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Build apps"
-weight: 200
-layout: "empty"
-type: "docs"
-empty_node: true
-open_on_desktop: true
-header_only: true
-canonical: "/operate/control/web-app/"
----
diff --git a/docs/operate/control/api-keys.md b/docs/operate/control/api-keys.md
deleted file mode 100644
index 8e6a708765..0000000000
--- a/docs/operate/control/api-keys.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: "Viam API keys"
-linkTitle: "API keys"
-weight: 50
-layout: "docs"
-type: "docs"
-description: "Run control logic on a machine."
-images: ["/general/code.png"]
-date: "2025-01-15"
----
-
-API keys grant access to organizations, locations, and machines.
-
-To view all API keys in use for your organization and the locations and machines inside it, click on the organization dropdown in the top navigation bar and click on **Settings**.
-
-{{<imgproc src="/fleet/api-keys.png" resize="700x" declaredimensions=true alt="API Keys table" class="shadow" >}}
-
-## Add an API key
-
-On your organization's page, click **Generate key** to generate a new key.
-Optionally, give the key a name.
-Click on the **Entity** menu and choose what organization, location, or machine you want the key to grant access to.
-If you select organization, your key grants access to all locations and machines contained within that organization.
-If you select location, your key grants access to all of the machines contained within that location.
-
-For **Role**, assign either an **Owner** or **Operator** role.
-See [Permissions](/manage/manage/rbac/) for information about the privilege each role entails at each resource level.
-
-## Change an API key's access
-
-To edit an API key, click on **Show details** in the key's row of the key table's **Entities** column.
-
-{{<imgproc src="/fleet/additional-details.png" resize="700x" declaredimensions=true alt="Additional details for a key" class="shadow" >}}
-
-To edit the role, click on the dropdown menu next to the role and select **Owner** or **Operator**.
-See [Permissions](/manage/manage/rbac/) for information about the privilege each role entails at each resource level.
-
-To change the entities it is able to access, click **+ Grant additional access**.
-Select which organization, location, or machine you want the key to grant access to.
-Click **Choose** to confirm your selection.
-
-## Rotate an API key
-
-Viam supports flexible key rotation with up to two keys in use at one time.
-If you ever need to rotate an API key you can use the web UI:
-
-1. On [Viam](https://app.viam.com/), click on the organization dropdown in the top navigation bar.
-1. Click on **Settings and invites**.
-1. Click the **Generate Key** button on the organization setting page to generate a new key.
-1. Update all code and integrations that use the key.
-1. Find the old API key on the page and click on **Show details**.
-1. Then click **Remove API key**.
-
-Alternatively, you can use the [`RotateKey`](/reference/apis/fleet/#rotatekey) API method.
diff --git a/docs/operate/control/headless-app.md b/docs/operate/control/headless-app.md
deleted file mode 100644
index 27d3bc5361..0000000000
--- a/docs/operate/control/headless-app.md
+++ /dev/null
@@ -1,411 +0,0 @@
----
-linkTitle: "Create a headless app"
-title: "Create a headless app"
-weight: 30
-layout: "docs"
-type: "docs"
-description: "Run control logic on a machine."
-images: ["/general/code.png"]
-aliases:
-  - /product-overviews/sdk-as-client/
-  - /program/sdk-as-client/
-  - /program/sdks/
-  - /program/
-  - /program/run/
-  - /program/debug/
-  - /how-tos/develop-app/
-  - /use-cases/develop-app/
-  - /product-overviews/sdk-as-client/
----
-
-To write control logic for your machine that will run without a user interface, you can use the Python, Go, or C++ SDK.
-The SDKs each include similar methods to hit Viam's [gRPC API](https://github.com/viamrobotics/api) endpoints.
-
-## Decide where to run your code
-
-You can run your code directly on the [machine's](/operate/install/setup/) single-board computer (SBC), or you can run it from a separate computer connected to the internet or to the same local network as your machine's SBC or microcontroller.
-
-### On a separate computer
-
-We recommend running your code on a laptop, desktop, or server if:
-
-- You are using computationally-intensive programs involving, for example, computer vision or motion planning, and
-- You have a stable internet connection
-
-The client code will establish a connection to the instance of `viam-server` on your machine's SBC over [LAN or WAN](/reference/sdks/connectivity/).
-
-### On the machine itself
-
-We recommend running your code on the SBC that directly controls your hardware if:
-
-- Your machines have intermittent or no network connectivity, or
-- You want to reduce latency, for example for running [PID control loops](https://en.wikipedia.org/wiki/Proportional%E2%80%93integral%E2%80%93derivative_controller), or
-- Your machine runs continuously (for example, an air quality sensor) and it is impractical to constantly run a client from your development computer
-
-## Install an SDK
-
-Install your preferred Viam SDK on the computer or SBC where you plan to run the control script.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-If you are using the Python SDK, [set up a virtual environment](/reference/sdks/python/python-venv/) to package the SDK inside before running your code, avoiding conflicts with other projects or your system.
-
-For macOS (both Intel `x86_64` and Apple Silicon) or Linux (`x86`, `aarch64`, `armv6l`), run the following commands:
-
-```sh {class="command-line" data-prompt="$"}
-python3 -m venv .venv
-source .venv/bin/activate
-pip install viam-sdk
-```
-
-Windows is not supported.
-If you are using Windows, use the [Windows Subsystem for Linux (WSL)](https://learn.microsoft.com/en-us/windows/wsl/install) and install the Python SDK using the preceding instructions for Linux.
-For other unsupported systems, see [Installing from source](https://python.viam.dev/#installing-from-source).
-
-If you intend to use the [ML (machine learning) model service](/vision/configure/), use the following command instead, which installs additional required dependencies along with the Python SDK:
-
-```sh {class="command-line" data-prompt="$"}
-pip install 'viam-sdk[mlmodel]'
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Run the following command to install the [Viam Go SDK](https://pkg.go.dev/go.viam.com/rdk):
-
-```sh {class="command-line" data-prompt="$"}
-go get go.viam.com/rdk/robot/client
-```
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-Follow the [instructions on the GitHub repository](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/BUILDING.md).
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Authenticate
-
-You can find sample connection code on each [machine's](/operate/install/setup/) **CONNECT** tab.
-Select your preferred **Language** to display a code snippet, with connection code as well as some calls to the APIs of the resources you've configured on your machine.
-
-You can use the toggle to include the machine API key and API key ID, though we strongly recommend storing your API keys in environment variables to reduce the risk of accidentally sharing your API key and granting access to your machines.
-
-If your code will connect to multiple machines or use [Platform APIs](/reference/apis/#platform-apis) you can create an API key with broader access.
-
-## Write your control code
-
-For API reference including code snippets for each method, see [Viam's Client APIs](/reference/apis/).
-
-{{< expand "Example code for moving a rover in a square" >}}
-
-The following code moves a mobile robot base in a square using the [base API](/reference/apis/components/base/).
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python {class="line-numbers linkable-line-numbers"}
-import asyncio
-
-from viam.components.base import Base
-from viam.robot.client import RobotClient
-from viam.rpc.dial import Credentials, DialOptions
-
-
-async def connect():
-    opts = RobotClient.Options.with_api_key(
-        # TODO: Replace "<API-KEY>" (including brackets) with your
-        # machine's API key
-        api_key='<API-KEY>',
-        # TODO: Replace "<API-KEY-ID>" (including brackets) with your machine's
-        # API key ID
-        api_key_id='<API-KEY-ID>'
-    )
-    # TODO: Replace "<MACHINE-ADDRESS>" with address from the CONNECT tab.
-    return await RobotClient.at_address('<MACHINE-ADDRESS>', opts)
-
-
-async def moveInSquare(base):
-    for _ in range(4):
-        # moves the rover forward 500mm at 500mm/s
-        await base.move_straight(velocity=500, distance=500)
-        print("move straight")
-        # spins the rover 90 degrees at 100 degrees per second
-        await base.spin(velocity=100, angle=90)
-        print("spin 90 degrees")
-
-
-async def main():
-    async with connect() as machine:
-        roverBase = Base.from_robot(machine, 'viam_base')
-
-        # Move the rover in a square
-        await moveInSquare(roverBase)
-
-
-if __name__ == '__main__':
-    asyncio.run(main())
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go {class="line-numbers linkable-line-numbers"}
-package main
-
-import (
-    "context"
-
-    "go.viam.com/rdk/components/base"
-    "go.viam.com/rdk/logging"
-    "go.viam.com/rdk/robot/client"
-    "go.viam.com/rdk/utils")
-
-func moveInSquare(ctx context.Context, base base.Base, logger logging.Logger) {
-    for i := 0; i < 4; i++ {
-        // moves the rover forward 600mm at 500mm/s
-        base.MoveStraight(ctx, 600, 500.0, nil)
-        logger.Info("move straight")
-        // spins the rover 90 degrees at 100 degrees per second
-        base.Spin(ctx, 90, 100.0, nil)
-        logger.Info("spin 90 degrees")
-    }
-}
-
-func main() {
-    logger := logging.NewLogger("client")
-    machine, err := client.New(
-      context.Background(),
-      // TODO: Replace "<MACHINE-ADDRESS>" with address from the CONNECT tab.
-      "<MACHINE-ADDRESS>",
-      logger,
-      client.WithDialOptions(utils.WithEntityCredentials(
-      // TODO: Replace "<API-KEY-ID>" (including brackets) with your machine's
-      // API key ID
-      "<API-KEY-ID>",
-      utils.Credentials{
-          Type:    utils.CredentialsTypeAPIKey,
-          // TODO: Replace "<API-KEY>" (including brackets) with your machine's
-          // API key
-          Payload: "<API-KEY>",
-      })),
-    )
-    if err != nil {
-        logger.Fatal(err)
-    }
-    defer machine.Close(context.Background())
-
-    // Get the base from the rover
-    roverBase, err := base.FromProvider(machine, "viam_base")
-    if err != nil {
-        logger.Fatalf("cannot get base: %v", err)
-    }
-
-    // Move the rover in a square
-    moveInSquare(context.Background(), roverBase, logger)
-}
-```
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-```cpp {class="line-numbers linkable-line-numbers"}
-#include <boost/optional.hpp>
-#include <string>
-#include <vector>
-#include <iostream>
-#include <unistd.h>
-#include <viam/sdk/common/instance.hpp>
-#include <viam/sdk/robot/client.hpp>
-#include <viam/sdk/components/motor.hpp>
-#include <viam/sdk/components/base.hpp>
-#include <viam/sdk/components/camera.hpp>
-#include <viam/sdk/components/encoder.hpp>
-
-using namespace viam::sdk;
-using std::cerr;
-using std::cout;
-using std::endl;
-
-void move_in_square(std::shared_ptr<viam::sdk::Base> base) {
-  for (int i = 0; i < 4; ++i) {
-    cout << "Move straight" << endl;
-    // Move the base forward 600mm at 500mm/s
-    base->move_straight(500, 500);
-    cout << "Spin" << endl;
-    // Spin the base by 90 degree at 100 degrees per second
-    base->spin(90, 100);
-  }
-}
-
-int main() {
-    // Every Viam C++ SDK program must have one and only one Instance object which is created
-    // before
-    // any other C++ SDK objects and stays alive until all Viam C++ SDK objects are destroyed.
-    Instance inst;
-
-    // TODO: Replace "<MACHINE-ADDRESS>" with address from the CONNECT tab.
-    std::string host("<MACHINE-ADDRESS>");
-    DialOptions dial_opts;
-    // TODO: Replace "<API-KEY-ID>" with your machine's API key ID
-    dial_opts.set_entity(std::string("<API-KEY-ID>"));
-    // TODO: Replace "<API-KEY>" with your machine's API key
-    Credentials credentials("api-key", "<API-KEY>");
-    dial_opts.set_credentials(credentials);
-    boost::optional<DialOptions> opts(dial_opts);
-    Options options(0, opts);
-
-    auto machine = RobotClient::at_address(host, options);
-
-    std::cout << "Resources:\n";
-    for (const Name& resource : machine->resource_names()) {
-      std::cout << "\t" << resource << "\n";
-    }
-
-    std::string base_name("viam_base");
-
-    cout << "Getting base: " << base_name << endl;
-    std::shared_ptr<Base> base;
-    try {
-        base = machine->resource_by_name<Base>(base_name);
-
-        move_in_square(base);
-
-    } catch (const std::exception& e) {
-        cerr << "Failed to find " << base_name << ". Exiting." << endl;
-        throw;
-    }
-    return EXIT_SUCCESS;
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< /expand >}}
-
-{{< expand "Example Python code for turning on a fan based on sensor readings" >}}
-
-The following example from [Automate air filtration with air quality sensors](https://codelabs.viam.com/guide/air-quality/index.html?index=..%2F..index#0) uses both the sensor API's [GetReadings](/reference/apis/components/sensor/#getreadings) command as well as custom functionality with the generic [DoCommand](/reference/apis/components/generic/#docommand).
-
-```python {class="line-numbers linkable-line-numbers"}
-import asyncio
-import os
-from dotenv import load_dotenv
-from viam.logging import getLogger
-from viam.robot.client import RobotClient
-from viam.components.sensor import Sensor
-from viam.components.generic import Generic
-
-load_dotenv()
-LOGGER = getLogger(__name__)
-
-robot_api_key = os.getenv('MACHINE_API_KEY') or ''
-robot_api_key_id = os.getenv('MACHINE_API_KEY_ID') or ''
-robot_address = os.getenv('MACHINE_ADDRESS') or ''
-
-# Define the sensor and plug names on the CONFIGURE tab
-sensor_name = os.getenv("SENSOR_NAME", "")
-plug_name = os.getenv("PLUG_NAME", "")
-
-
-async def connect():
-    opts = RobotClient.Options.with_api_key(
-        api_key=robot_api_key,
-        api_key_id=robot_api_key_id
-    )
-    return await RobotClient.at_address(robot_address, opts)
-
-
-async def main():
-    async with connect() as machine:
-        pms_7003 = Sensor.from_robot(machine, sensor_name)
-        kasa_plug = Generic.from_robot(machine, plug_name)
-
-        # Define unhealthy thresholds
-        unhealthy_thresholds = {
-            'pm2_5_atm': 35.4,
-            'pm10_atm': 150
-        }
-
-        while True:
-            readings = await pms_7003.get_readings()
-            # Check if any of the PM values exceed the unhealthy thresholds
-            if any(readings.get(pm_type, 0) > threshold for pm_type,
-                    threshold in unhealthy_thresholds.items()):
-                LOGGER.info('UNHEALTHY.')
-                await kasa_plug.do_command({"toggle_on": []})
-            else:
-                LOGGER.info('HEALTHY!')
-                await kasa_plug.do_command({"toggle_off": []})
-
-            # wait before checking again
-            await asyncio.sleep(10)
-
-if __name__ == '__main__':
-    asyncio.run(main())
-```
-
-{{< /expand >}}
-
-## Run your code
-
-You can run your code manually from your terminal, or you can automatically run it each time your machine starts.
-
-### Run your code manually
-
-To run your code on a laptop or desktop, or to run it on your machine's SBC manually for testing purposes, execute the following command in a terminal:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-python3 /home/myName/project/my_cool_script.py
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-go run /home/myName/project/my_cool_script.go
-```
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-For information on running C++ code see [the instructions on GitHub](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/BUILDING.md).
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Run your control code in a module
-
-To run your control code on your machine, create a {{< glossary_tooltip term_id="module" text="module" >}} and deploy it to your machine.
-You can add functionality to the `DoCommand()` method to, for example, start and stop the control code.
-
-For more information, see [Create a module with machine control logic](/operate/modules/write-a-logic-module/#5-implement-docommand).
-
-## Debug
-
-Read and filter a machine's logs to view updates from your machine's `viam-server` instance and troubleshoot issues with your program.
-
-{{< tabs >}}
-{{% tab name="App UI" %}}
-
-Navigate to the **LOGS** tab of your machine's page.
-
-Select from the **Levels** dropdown menu to filter the logs by severity level:
-
-![Filtering by log level of info in the logs tab.](/build/program/sdks/log-level-info.png)
-
-{{% /tab %}}
-{{% tab name="Command line" %}}
-
-```sh {class="command-line" data-prompt="$"}
-viam machines part logs --part=<part-id> --tail=true
-```
-
-{{% /tab %}}
-{{< /tabs >}}
diff --git a/docs/operate/control/kiosk-app.md b/docs/operate/control/kiosk-app.md
deleted file mode 100644
index e77f552493..0000000000
--- a/docs/operate/control/kiosk-app.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Create a kiosk app"
-title: "Create a kiosk app"
-weight: 40
-layout: "docs"
-type: "docs"
-no_list: true
-description: "TODO"
-draft: true
----
diff --git a/docs/operate/control/mobile-app.md b/docs/operate/control/mobile-app.md
deleted file mode 100644
index 2606ce0618..0000000000
--- a/docs/operate/control/mobile-app.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-linkTitle: "Create a mobile app"
-title: "Create a mobile app"
-weight: 20
-layout: "docs"
-type: "docs"
-description: "Create a custom user interface for interacting with machines from a mobile device."
----
-
-You can use Viam's [Flutter SDK](https://flutter.viam.dev/) to create a custom mobile application to interact with your devices.
-The Flutter SDK includes:
-
-- Implementation of the standard component and service APIs to control your hardware and software
-- Widgets to ease the development process
-- Authentication tools so users can log in securely
-
-## Install the Flutter SDK
-
-Run the following command in your terminal to install the Viam Flutter SDK:
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-flutter pub add viam_sdk
-```
-
-## Connect to your machine
-
-You can find sample connection code on each [machine's](/operate/install/setup/) **CONNECT** tab.
-Select **Flutter** to display a code snippet with connection code as well as some calls to the APIs of the resources you've configured on your machine.
-
-You can use the toggle to include the machine API key and API key ID, though we strongly recommend storing your API keys in environment variables to reduce the risk of accidentally sharing your API key and granting access to your machines.
-
-If your code will connect to multiple machines or use [Platform APIs](/reference/apis/#platform-apis) you can create an API key with broader access.
-
-## Write your app
-
-Refer to the [Viam Flutter SDK](https://flutter.viam.dev/) documentation for available methods and widgets.
-
-### Example usage
-
-The following code, part of [Drive a rover in a square in 2 minutes](/tutorials/control/drive-rover/), shows how you could move a robotic rover base in a square using the base API's [`moveStraight`](https://flutter.viam.dev/viam_sdk/Base/moveStraight.html) and [`spin`](https://flutter.viam.dev/viam_sdk/Base/spin.html) methods:
-
-```dart {class="line-numbers linkable-line-numbers"}
-import 'package:flutter/material.dart';
-import 'package:viam_sdk/viam_sdk.dart';
-import 'package:viam_sdk/widgets.dart';
-
-class BaseScreen extends StatelessWidget {
-  final Base base;
-
-  const BaseScreen(this.base, {super.key});
-
-  Future<void> moveSquare() async {
-    for (var i=0; i<4; i++) {
-      await base.moveStraight(500, 500);
-      await base.spin(90, 100);
-    }
-  }
-
-  @override
-  Widget build(BuildContext context) {
-    return Scaffold(
-      appBar: AppBar(title: Text(base.name)),
-      body: Center(
-        child: Column(
-        mainAxisAlignment: MainAxisAlignment.center,
-        children: [
-          ElevatedButton(
-              onPressed: moveSquare,
-              child: const Text('Move Base in Square'),
-            ),
-        ]))
-        ,);}}
-```
-
-{{<video webm_src="/tutorials/try-viam-sdk/square-test-rover.webm" mp4_src="/tutorials/try-viam-sdk/square-test-rover.mp4" alt="An example flutter app moving a Try Viam rover in a square" poster="/tutorials/try-viam-sdk/square-test-rover.jpg">}}
-
-See the guide for full code and instructions to get started by building a simple app to control a rented Viam rover:
-
-{{< cards >}}
-{{% card link="/tutorials/control/drive-rover/" %}}
-{{< /cards >}}
-
-For a more in-depth guide with more screens, see the following guide:
-
-{{< cards >}}
-{{% card link="/tutorials/control/flutter-app/" %}}
-{{< /cards >}}
-
-## Test your app
-
-You can use the mobile app simulator on your development computer to test your app.
-The connection code will establish communication with your machine over LAN or WAN.
-
-## Set up user authentication through Viam
-
-Viam uses [FusionAuth](https://fusionauth.io/) for authentication and authorization.
-
-You can [use Viam to authenticate end users](/manage/manage/oauth/) while using a branded login screen.
-
-## Next steps
-
-To publish your app to the app stores when you're done testing and adding authentication, see Flutter's articles:
-
-- [iOS](https://docs.flutter.dev/deployment/ios)
-- [Android](https://docs.flutter.dev/deployment/android)
diff --git a/docs/operate/control/sdks.md b/docs/operate/control/sdks.md
deleted file mode 100644
index 201a8db661..0000000000
--- a/docs/operate/control/sdks.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: "SDKs"
-linkTitle: "SDKs"
-weight: 40
-type: "docs"
-layout: "empty"
-canonical: "/reference/sdks/"
----
diff --git a/docs/operate/control/viam-applications.md b/docs/operate/control/viam-applications.md
deleted file mode 100644
index 4251ef1746..0000000000
--- a/docs/operate/control/viam-applications.md
+++ /dev/null
@@ -1,434 +0,0 @@
----
-title: "Create a Viam application"
-linkTitle: "Create a Viam application"
-weight: 5
-layout: "docs"
-type: "docs"
-description: "Create and deploy a custom web interface for your machines without managing hosting infrastructure and authentication."
-videos: ["/spa.webm", "/spa.mp4"]
-videoAlt: "Logging into a viam application."
-images: ["/spa.gif"]
----
-
-Create and deploy a custom web interface for your machines without managing hosting infrastructure and authentication.
-Once deployed, your application is accessible from a dedicated URL (`appname_publicnamespace.viamapplications.com`), and Viam handles hosting and authentication.
-
-Users log in and the application then renders your custom interface for interacting with the user's machines.
-You can choose to build an application that can access and operate a single-machine or multiple machines.
-
-## Requirements
-
-{{< expand "Install the Viam CLI and authenticate." >}}
-Install the Viam CLI using the option below that matches your system architecture:
-
-{{< readfile "/static/include/how-to/install-cli.md" >}}
-
-Then authenticate your CLI session with Viam using one of the following options:
-
-{{< readfile "/static/include/how-to/auth-cli.md" >}}
-
-{{< /expand >}}
-
-## Build a custom web interface
-
-You can build a custom web interface to access your machines using your preferred framework like React, Vue, Angular, or others.
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Access machines from your application**
-
-When logging into a Viam application, Viam stores an access token in the user's browser.
-For single-machine applications, Viam stores an access token and several machine-specific cookies.
-
-Access the data from the browser's cookies and use it to make API calls:
-
-{{< tabs >}}
-{{% tab name="Single-machine application" %}}
-
-```ts {class="line-numbers linkable-line-numbers" data-line=""}
-import * as VIAM from "@viamrobotics/sdk";
-import Cookies from "js-cookie";
-
-let apiKeyId = "";
-let apiKeySecret = "";
-let host = "";
-let machineId = "";
-
-async function main() {
-  const opts: VIAM.ViamClientOptions = {
-    serviceHost: "https://app.viam.com",
-    credentials: {
-      type: "api-key",
-      payload: apiKeySecret,
-      authEntity: apiKeyId,
-    },
-  };
-
-  const client = await VIAM.createViamClient(opts);
-  const machine = await client.appClient.getRobot(machineId);
-}
-
-document.addEventListener("DOMContentLoaded", async () => {
-  // Extract the machine identifier from the URL
-  let machineCookieKey = window.location.pathname.split("/")[2];
-  ({
-    apiKey: { id: apiKeyId, key: apiKeySecret },
-    machineId: machineId,
-    hostname: host,
-  } = JSON.parse(Cookies.get(machineCookieKey)!));
-
-  main().catch((error) => {
-    console.error("encountered an error:", error);
-  });
-});
-```
-
-{{% /tab %}}
-{{% tab name="Multi-machine application" %}}
-
-```ts {class="line-numbers linkable-line-numbers" data-line=""}
-import * as VIAM from "@viamrobotics/sdk";
-import Cookies from "js-cookie";
-
-let access_token = "";
-// optionally specify a fragmentID to use with the listMachineSummaries API call
-let fragmentID = "";
-
-async function main() {
-  const opts: VIAM.ViamClientOptions = {
-    serviceHost: "https://app.viam.com",
-    credentials: {
-      type: "access-token",
-      payload: access_token,
-    },
-  };
-
-  const client = await VIAM.createViamClient(opts);
-  const locationSummaries = await client.appClient.listMachineSummaries("", [
-    fragmentID,
-  ]);
-}
-
-document.addEventListener("DOMContentLoaded", async () => {
-  const userTokenRawCookie = Cookies.get("userToken")!;
-  const startIndex = userTokenRawCookie.indexOf("{");
-  const endIndex = userTokenRawCookie.indexOf("}");
-  const userTokenValue = userTokenRawCookie.slice(startIndex, endIndex + 1);
-  access_token = JSON.parse(userTokenValue).access_token;
-
-  main().catch((error) => {
-    console.error("encountered an error:", error);
-  });
-});
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Configure routing**
-
-{{< tabs >}}
-{{% tab name="Single-machine application" %}}
-
-When using your deployed application, static files will be accessible at `https://your-app-name_your-public-namespace.viamapplications.com/machine/<machineHostname>/`.
-
-{{% /tab %}}
-{{% tab name="Multi-machine application" %}}
-
-When using your deployed application, static files will be accessible at `https://your-app-name_your-public-namespace.viamapplications.com/`.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-If your HTML file loads other files, use relative paths to ensure your files are accessible.
-
-{{% /tablestep %}}
-{{< /table >}}
-
-## Local development
-
-For developing your application on localhost:
-
-1. Run your web server. Take note of its port number for the next step.
-1. Run the following commands specifying the address where your app is running on localhost and a machine to test on.
-
-   {{< tabs >}}
-   {{% tab name="Single-machine application" %}}
-
-   The command will proxy your local app and open a browser window and navigate to `http://localhost:8012/machine/<machineHostname>` for the machine provided with --machine-id.
-
-{{< tabs >}}
-{{% tab name="Template" %}}
-
-```sh {class="command-line" data-prompt="$" data-output="3-10"}
-viam login
-viam module local-app-testing --app-url http://localhost:<PORT-YOUR-WEB-SERVER-IS-ON> --machine-id <MACHINE-ID>
-```
-
-{{% /tab %}}
-{{% tab name="Example" %}}
-
-```sh {class="command-line" data-prompt="$" data-output="3-10"}
-viam login
-viam module local-app-testing --app-url http://localhost:3000 --machine-id a1b2c3d4-e5f6-7890-abcd-ef1234567890
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="Multi-machine application" %}}
-
-The command will proxy your local app and open a browser window and navigate to `http://localhost:8012/`.
-
-{{< tabs >}}
-{{% tab name="Template" %}}
-
-```sh {class="command-line" data-prompt="$" data-output="3-10"}
-viam login
-viam module local-app-testing --app-url http://localhost:<PORT>
-```
-
-{{% /tab %}}
-{{% tab name="Example" %}}
-
-```sh {class="command-line" data-prompt="$" data-output="3-10"}
-viam login
-viam module local-app-testing --app-url http://localhost:3000
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Deploy your web interface
-
-To deploy your web interface with Viam, you must create a FILE>meta.json</FILE> file and package it with yoru web application as a module.
-
-{{< table >}}
-{{% tablestep start=1 %}}
-
-**Create a <FILE>meta.json</FILE>** file for your module using this template.
-
-Viam uses the <FILE>meta.json</FILE> file to add some customizations to the authentication screen of your application and to display it in the Viam Registry.
-
-{{< tabs >}}
-{{% tab name="Template" %}}
-
-```json
-{
-  "module_id": "your-namespace:your-module",
-  "visibility": "public",
-  "url": "https://github.com/your-org/your-repo",
-  "description": "Your module description",
-  "applications": [
-    {
-      "name": "your-app-name",
-      "type": "single_machine|multi_machine",
-      "entrypoint": "dist/index.html",
-      "fragmentIds": [],
-      "logoPath": "static/logo.png",
-      "customizations": {
-        "machinePicker": {
-          "heading": "Heading to display on branded authentication page",
-          "subheading": "Subheading to display on branded authentication page"
-        }
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Example" %}}
-
-```json
-{
-  "module_id": "acme:dashboard",
-  "visibility": "public",
-  "url": "https://github.com/acme/dashboard",
-  "description": "An example dashboard for a fictitious air quality company called acme.",
-  "applications": [
-    {
-      "name": "dashboard",
-      "type": "single_machine",
-      "entrypoint": "dist/index.html",
-      "fragmentIds": [],
-      "logoPath": "static/logo.png",
-      "customizations": {
-        "machinePicker": {
-          "heading": "Air monitoring dashboard",
-          "subheading": "Sign in and select your devices to view your air quality metrics in a dashboard."
-        }
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-This file specifies the contents of the module.
-It is required for your module.
-
-{{% expand "Click to view more information on attributes." %}}
-
-<!-- prettier-ignore -->
-| Name | Type | Inclusion | Description |
-|------|------|-----------|-------------|
-| `module_id` | string | **Required** | The module ID, which includes either the module namespace or organization ID, followed by its name: `<namespace>:<module-name>` or `<org-id>:<module-name>`. The `module_id` uniquely identifies your module. |
-| `visibility` | string | **Required** | Must be `"public"`. |
-| `description` | string | **Required** | The description of your module and what it provides. |
-| `url` | string | Optional | The URL of the GitHub repository containing the source code of the module. |
-| `applications` | array | Optional | Objects that provide information about the [applications](/operate/control/viam-applications/) associated with the module. |
-| `models` | array | Optional | Deprecated. Empty unless you are shipping the app alongside models. For information on how to add models, see [Support hardware and software](/operate/modules/write-a-driver-module/). |
-
-{{% /expand%}}
-
-The `applications` field is an array of application objects with the following properties:
-
-<!-- prettier-ignore -->
-| Property     | Type   | Description |
-| ------------ | ------ | ----------- |
-| `name`       | string | The name of your application, which will be a part of the application's URL (`name_publicnamespace.viamapplications.com`). For more information on valid names see [Valid application identifiers](/operate/modules/advanced/metajson/#valid-application-identifiers). |
-| `type` | string | The type of application: `"single_machine"` or `"multi_machine"`. Whether the application can access and operate one machine or multiple machines. |
-| `entrypoint` | string | The path to the HTML entry point for your application. The `entrypoint` field specifies the path to your application's entry point. For example: <ul><li><code>"dist/index.html"</code>: Static content rooted at the `dist` directory</li><li><code>"dist/foo.html"</code>: Static content rooted at the `dist` directory, with `foo.html` as the entry point</li><li><code>"dist/"</code>: Static content rooted at the `dist` directory (assumes `dist/index.html` exists)</li><li><code>"dist/bar/foo.html"</code>: Static content rooted at `dist/bar` with `foo.html` as the entry point</li></ul> |
-| `fragmentIds` | []string | Specify the fragment or fragments that a machine must contain to be selectable from the machine picker screen. Only for single machine applications. |
-| `logoPath` | string | The URL or the relative path to the logo to display on the machine picker screen for a single machine application. |
-| `customizations` | object | Override the branding heading and subheading to display on the authentication screen for single machine applications: <ul><li>`heading`: Override the heading. May not be longer than 60 characters. </li><li>`subheading` Override the subheading. May not be longer than 256 characters.</li></ul> Example: `{ "heading": "Air monitoring dashboard", "subheading": "Sign in and select your devices to view your air quality metrics in a dashboard" }`. |
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Register your module** with Viam:
-
-{{< tabs >}}
-{{% tab name="Template" %}}
-
-```sh {class="command-line" data-prompt="$" data-output="3-10"}
-viam module create --name="app-name" --public-namespace="namespace"
-```
-
-{{% /tab %}}
-{{% tab name="Example" %}}
-
-```sh {class="command-line" data-prompt="$" data-output="3-10"}
-viam module create --name="air-quality" --public-namespace="naomi"
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-
-To deploy your application with Viam you must package your static files and your <FILE>meta.json</FILE> file as a module and upload them to the Viam Registry:
-
-```sh {class="command-line" data-prompt="$" data-output="3-10"}
-tar -czvf module.tar.gz <static-website-files> meta.json
-viam module upload --upload=module.tar.gz --platform=any --version=0.0.1
-```
-
-For subsequent updates run these commands again with an updated version number.
-
-{{% /tablestep %}}
-{{< /table >}}
-
-## Access your application
-
-After uploading your module with the application configuration, your application will be available at:
-
-```txt
-https://your-app-name_your-public-namespace.viamapplications.com
-```
-
-Users will be prompted to authenticate with their Viam credentials before accessing your application:
-
-1. User navigates to `your-app-name_your-public-namespace.viamapplications.com`.
-1. User authenticates with Viam credentials.
-1. For single-machine applications, the user selects an organization, location, and machine and is redirected to `your-app-name_your-public-namespace.viamapplications.com/machine/<machineHostname>`.
-   For multi-machine applications, the user is redirected to `your-app-name_your-public-namespace.viamapplications.com/`.
-1. Your application is rendered with access to the selected machine.
-   The credentials for that one machine are provided in the cookies.
-
-{{< tabs >}}
-{{% tab name="Single-machine application example" %}}
-
-{{<gif webm_src="/spa.webm" mp4_src="/spa.mp4" alt="Login screen with machine selection" max-width="500px">}}
-
-{{% /tab %}}
-{{% tab name="Multi-machine application example" %}}
-
-{{<gif webm_src="/air-quality-loading.webm" mp4_src="/air-quality-loading.mp4" alt="Login screen" max-width="500px">}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Examples
-
-- For a multi-machine TypeScript application see [Monitor Air Quality with a Fleet of Sensors](/tutorials/control/air-quality-fleet/).
-
-- For a single-machine React application that shows camera feeds for a machine, see [Viam Camera Viewer](https://github.com/viam-labs/viam-camera-viewer).
-
-## Limitations
-
-- All modules with applications must have public visibility.
-- The page will always render the latest version.
-- Browsers with cookies disabled are not supported.
-- Viam applications serve static files.
-  If you are building an application with server-side rendering or need other back-end capabilities, Viam applications is not the right choice.
-
-## Security considerations
-
-- Customer applications are stored publicly on the internet, so avoid uploading sensitive information in your application code or assets.
-- API keys and secrets are stored in the browser's cookies.
-- Users authenticate with FusionAuth.
-
-## FAQ
-
-### Can I use a custom domain?
-
-Viam does not currently support using custom domains (for example: `app.mycustomdomain.com/machine/<machineHostname>`) to serve your Viam application.
-You can, however, redirect from your domain to your Viam application (`app.mycustomdomain.com` -> `your-app-name_your-public-namespace.viamapplications.com`).
-You can configure a redirect (HTTP 301) on your web server or hosting provider from `app.mycustomdomain.com/*` to `your-app-name_your-public-namespace.viamapplications.com/*`.
-
-### How can I add external API keys?
-
-You can store API keys for use with Viam apps as part of robot metadata:
-
-{{< tabs >}}
-{{% tab name="Web UI" %}}
-
-1. On a machine page, lick on the **...** menu in the top-right corner.
-1. Select **Custom machine metadata**.
-1. Add the metadata to the JSON object.
-1. Click **Save**.
-
-{{% /tab %}}
-{{% tab name="Python" %}}
-
-{{< read-code-snippet file="/static/include/examples-generated/add-metadata.snippet.add-metadata.py" lang="py" class="line-numbers linkable-line-numbers" data-line="41-43" >}}
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-{{< read-code-snippet file="/static/include/examples-generated/add-metadata.snippet.add-metadata.go" lang="go" class="line-numbers linkable-line-numbers" data-line="50-52" >}}
-
-{{% /tab %}}
-{{% tab name="TypeScript" %}}
-
-{{< read-code-snippet file="/static/include/examples-generated/add-metadata.snippet.add-metadata.ts" lang="ts" class="line-numbers linkable-line-numbers" data-line="37-39" >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Then you can access these API keys from within your app:
-
-```ts {class="line-numbers linkable-line-numbers"}
-const metadata = await appClient.getRobotMetadata("<YOUR-MACHINE-ID>");
-const key = metadata.TEST_API_KEY;
-```
diff --git a/docs/operate/control/voice-app.md b/docs/operate/control/voice-app.md
deleted file mode 100644
index 8a740274bc..0000000000
--- a/docs/operate/control/voice-app.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Create voice-interface app"
-title: "Create voice-interface app"
-weight: 30
-layout: "docs"
-type: "docs"
-no_list: true
-description: "TODO"
-draft: true
----
diff --git a/docs/operate/control/web-app.md b/docs/operate/control/web-app.md
deleted file mode 100644
index 415cf7d1f2..0000000000
--- a/docs/operate/control/web-app.md
+++ /dev/null
@@ -1,368 +0,0 @@
----
-linkTitle: "Create a web app"
-title: "Create a web app"
-weight: 10
-layout: "docs"
-type: "docs"
-description: "Create a custom user interface for interacting with machines from a browser."
----
-
-You can use Viam's [TypeScript SDK](https://ts.viam.dev/) to create a custom web application to interact with your devices.
-The TypeScript SDK includes:
-
-- Implementation of the standard component and service APIs to control your hardware and software
-- Authentication tools so users can log in securely
-
-{{< alert title="Tip: Host your application on Viam" color="tip" >}}
-You can host most apps by [deploying them as Viam applications](/operate/control/viam-applications/).
-If your application requires server-side rendering or other back-end functionality, self-host your application instead.
-{{< /alert >}}
-
-## Install the TypeScript SDK
-
-Run the following command in your terminal to install the Viam TypeScript SDK:
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-npm install @viamrobotics/sdk
-```
-
-## Connect to your machine
-
-You can find sample connection code on each [machine's](/operate/install/setup/) **CONNECT** tab.
-Select **TypeScript** to display a code snippet, with connection code as well as some calls to the APIs of the resources you've configured on your machine.
-
-You can use the toggle to include the machine API key and API key ID, though we strongly recommend storing your API keys in environment variables to reduce the risk of accidentally sharing your API key and granting access to your machines.
-
-If your code will connect to multiple machines or use [Platform APIs](/reference/apis/#platform-apis) you can create an API key with broader access.
-
-## Write your app
-
-Refer to the [Viam TypeScript SDK](https://ts.viam.dev/) documentation for available methods.
-
-### Example: A camera and sensor dashboard
-
-The following files create an example TypeScript web app that connects to a machine and displays the latest image from the machine's camera, and the latest sensor readings.
-
-{{<imgproc src="/operate/ts-dashboard.png" resize="x1100" declaredimensions=true alt="A web browser displaying a dashboard with a camera feed and sensor readings." style="width:450px" class="imgzoom" >}}
-
-{{< tabs >}}
-{{% tab name="main.ts" %}}
-
-<file>main.ts</file> connects to the machine and accesses the camera and sensor:
-
-```ts {class="line-numbers linkable-line-numbers"}
-// This code must be run in a browser environment.
-import * as VIAM from "@viamrobotics/sdk";
-import { CameraClient, SensorClient, StreamClient } from "@viamrobotics/sdk";
-
-let isStreaming = false;
-let camera: CameraClient;
-let stream: StreamClient;
-let animationFrameId: number;
-let machine: VIAM.RobotClient;
-
-const main = async () => {
-  const host = "demo-main.abcdefg1234.viam.cloud";
-
-  machine = await VIAM.createRobotClient({
-    host,
-    credentials: {
-      type: "api-key",
-      /* Replace "<API-KEY>" (including brackets) with your machine's API key */
-      payload: "<API-KEY>",
-      /* Replace "<API-KEY-ID>" (including brackets) with your machine's API key ID */
-      authEntity: "<API-KEY-ID>",
-    },
-    signalingAddress: "https://app.viam.com:443",
-  });
-
-  try {
-    // Get the camera and stream clients
-    camera = new CameraClient(machine, "camera-1");
-
-    // Start the camera stream
-    startStream();
-
-    // Get readings from sensor
-    const sensor = new SensorClient(machine, "sensor-1");
-    const readings = await sensor.getReadings();
-
-    // Create HTML to display sensor readings
-    const readingsHtml = document.createElement("div");
-    for (const [key, value] of Object.entries(readings)) {
-      const reading = document.createElement("p");
-      reading.textContent = `${key}: ${value}`;
-      readingsHtml.appendChild(reading);
-    }
-
-    // Display the readings
-    const readingsContainer = document.getElementById("insert-readings");
-    if (readingsContainer) {
-      readingsContainer.innerHTML = "";
-      readingsContainer.appendChild(readingsHtml);
-    }
-
-    // Add refresh button functionality
-    const refreshButton = document.getElementById("refresh-button");
-    if (refreshButton) {
-      refreshButton.onclick = async () => {
-        try {
-          const newReadings = await sensor.getReadings();
-          const readingsHtml = document.createElement("div");
-          for (const [key, value] of Object.entries(newReadings)) {
-            const reading = document.createElement("p");
-            reading.textContent = `${key}: ${value}`;
-            readingsHtml.appendChild(reading);
-          }
-
-          if (readingsContainer) {
-            readingsContainer.innerHTML = "";
-            readingsContainer.appendChild(readingsHtml);
-          }
-        } catch (error) {
-          console.error("Error refreshing sensor data:", error);
-        }
-      };
-    }
-  } catch (error) {
-    console.error("Error:", error);
-    const errorMessage = `<p>Error: ${error instanceof Error ? error.message : "Failed to get data"}</p>`;
-
-    const imageContainer = document.getElementById("insert-stream");
-    if (imageContainer) {
-      imageContainer.innerHTML = errorMessage;
-    }
-
-    const readingsContainer = document.getElementById("insert-readings");
-    if (readingsContainer) {
-      readingsContainer.innerHTML = errorMessage;
-    }
-  }
-
-  // Add cleanup on page unload
-  window.addEventListener("beforeunload", () => {
-    stopStream();
-    machine.disconnect();
-  });
-};
-
-const updateCameraStream = async () => {
-  if (!isStreaming) return;
-
-  try {
-    const imageContainer = document.getElementById("insert-stream");
-    if (imageContainer) {
-      // Create or update video element
-      let videoElement = imageContainer.querySelector("video");
-      if (!videoElement) {
-        videoElement = document.createElement("video");
-        videoElement.autoplay = true;
-        videoElement.muted = true;
-        imageContainer.innerHTML = "";
-        imageContainer.appendChild(videoElement);
-      }
-
-      // Get and set the stream every frame
-      const mediaStream = await stream.getStream("camera-1");
-      videoElement.srcObject = mediaStream;
-
-      // Ensure video plays
-      try {
-        await videoElement.play();
-      } catch (playError) {
-        console.error("Error playing video:", playError);
-      }
-    }
-
-    // Request next frame
-    animationFrameId = requestAnimationFrame(() => updateCameraStream());
-  } catch (error) {
-    console.error("Stream error:", error);
-    stopStream();
-  }
-};
-
-const startStream = () => {
-  // Initialize stream client
-  stream = new StreamClient(machine);
-  isStreaming = true;
-  updateCameraStream();
-};
-
-const stopStream = () => {
-  isStreaming = false;
-  if (animationFrameId) {
-    cancelAnimationFrame(animationFrameId);
-  }
-};
-
-main().catch((error: unknown) => {
-  console.error("encountered an error:", error);
-});
-```
-
-{{% /tab %}}
-{{% tab name="index.html" %}}
-
-<file>static/index.html</file> defines the HTML structure of the web app:
-
-```html {class="line-numbers linkable-line-numbers"}
-<!doctype html>
-<html>
-  <head>
-    <link rel="stylesheet" href="style.css" />
-  </head>
-
-  <body>
-    <div id="main">
-      <div>
-        <h1>My Dashboard</h1>
-      </div>
-      <script type="module" src="main.js"></script>
-      <div>
-        <h2>Camera Feed</h2>
-        <p>Live view from the machine's camera:</p>
-      </div>
-      <div id="insert-stream">
-        <p>
-          <i
-            >Loading stream... It may take a few moments for the stream to load.
-            Do not refresh page.</i
-          >
-        </p>
-      </div>
-      <div>
-        <h2>Sensor Data</h2>
-        <p>Recent readings from the machine's sensor:</p>
-      </div>
-      <div id="insert-readings">
-        <p>
-          <i
-            >Loading data... It may take a few moments for the data to load. Do
-            not refresh page.</i
-          >
-        </p>
-      </div>
-      <br />
-      <button id="refresh-button">Refresh Data</button>
-    </div>
-  </body>
-</html>
-```
-
-{{% /tab %}}
-{{% tab name="style.css" %}}
-
-<file>static/style.css</file> defines the CSS styles for the web app:
-
-```css {class="line-numbers linkable-line-numbers"}
-body {
-  margin: 0;
-  padding: 0;
-  background-color: #f0f2f5;
-  font-family: "Segoe UI", Arial, sans-serif;
-  color: #1a1a1a;
-}
-
-#main {
-  max-width: 1200px;
-  margin: 20px 20px;
-  padding: 30px;
-  background-color: white;
-  border-radius: 12px;
-  box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);
-}
-
-h1 {
-  color: #2c3e50;
-  margin-bottom: 30px;
-  font-size: 2.2em;
-}
-
-h2 {
-  color: #34495e;
-  margin-top: 30px;
-  font-size: 1.5em;
-}
-
-div {
-  background-color: transparent;
-}
-
-video {
-  background: black;
-  border-radius: 8px;
-}
-
-button#refresh-button {
-  padding: 12px 24px;
-  font-size: 16px;
-  background-color: #4caf50;
-  color: white;
-  border: none;
-  border-radius: 6px;
-  cursor: pointer;
-  transition: background-color 0.2s ease;
-  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
-}
-
-button#refresh-button:hover {
-  background-color: #45a049;
-}
-
-p {
-  line-height: 1.6;
-  color: #4a4a4a;
-}
-```
-
-{{% /tab %}}
-{{% tab name="package.json" %}}
-
-<file>package.json</file> defines the dependencies and scripts for the web app:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "my-ts-dashboard",
-  "description": "A dashboard for getting an image from a machine.",
-  "scripts": {
-    "start": "esbuild ./main.ts --bundle --outfile=static/main.js --servedir=static --format=esm",
-    "test": "echo \"Error: no test specified\" && exit 1"
-  },
-  "author": "<YOUR NAME>",
-  "license": "ISC",
-  "devDependencies": {
-    "esbuild": "*"
-  },
-  "dependencies": {
-    "@viamrobotics/sdk": "^0.38.0",
-    "bson": "^6.10.0"
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### More examples
-
-For an example using Vite to connect to a machine, see [Viam's vanilla TypeScript quickstart example on GitHub](https://github.com/viamrobotics/viam-typescript-sdk/tree/main/examples/vanilla).
-
-The following tutorial uses the Viam TypeScript SDK to query data that has been uploaded to the Viam cloud from a sensor, and display it in a web dashboard.
-
-{{< cards >}}
-{{% card link="/tutorials/control/air-quality-fleet/" %}}
-{{< /cards >}}
-
-## Test your app
-
-You can run your app directly on the machine's single-board computer (SBC) if applicable, or you can run it from a separate computer connected to the internet or to the same local network as your machine's SBC or microcontroller.
-The connection code will establish communication with your machine over LAN or WAN.
-
-You can also host your app on a server or hosting service of your choice.
-
-## Set up user authentication through Viam
-
-Viam uses [FusionAuth](https://fusionauth.io/) for authentication and authorization.
-
-You can [use Viam to authenticate end users](/manage/manage/oauth/) while using a branded login screen.
diff --git a/docs/operate/hello-world/_index.md b/docs/operate/hello-world/_index.md
deleted file mode 100644
index 7fbceea6f2..0000000000
--- a/docs/operate/hello-world/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Learn Viam"
-weight: 50
-layout: "empty"
-type: "docs"
-empty_node: true
-open_on_desktop: true
-header_only: true
-canonical: "/operate/hello-world/what-is-viam/"
----
diff --git a/docs/operate/hello-world/building.md b/docs/operate/hello-world/building.md
deleted file mode 100644
index ac17d1fae1..0000000000
--- a/docs/operate/hello-world/building.md
+++ /dev/null
@@ -1,513 +0,0 @@
----
-linkTitle: "How to build a machine"
-title: "How to think about building a machine"
-weight: 30
-layout: "docs"
-type: "docs"
-images: ["/icons/components.png"]
-imageAlt: "Viam building blocks"
-description: "Viam works by breaking complex projects into composable building blocks. Your project's complexities become manageable and you gain flexibility."
-modulescript: true
-aliases:
-  - "/tutorials/build-a-mock-robot/"
-  - "/tutorials/how-to-build-a-mock-robot/"
-  - "/tutorials/configure/build-a-mock-robot/"
-date: "2025-10-09"
----
-
-Viam adapts software engineering paradigms to building machines for the physical world.
-At its core, Viam works by breaking complex projects into composable building blocks.
-With this approach, your project's complexities become manageable, and more importantly, you gain flexibility and testability.
-
-The flexibility means you can, at any point, swap out hardware, change logic, or even switch programming language.
-
-To accomplish this, you must adopt a _modular_ way of thinking.
-
-{{< alert title="You will learn about" color="note" >}}
-
-1. [Identifying the building blocks for your project](#step-1-identify-the-building-blocks)
-1. [Starting with a minimal prototype](#step-2-start-with-a-minimal-prototype)
-1. [Adding your control logic](#step-3-add-your-control-logic)
-1. [Testing and Iterating](#step-4-test-and-iterate)
-1. [Considering resource constraints and scaling](#step-5-consider-resource-constraints-and-scaling)
-1. [Building a UI](#step-6-build-a-ui)
-1. [Scaling and production](#step-7-scaling-and-production)
-
-{{< /alert >}}
-
-This guide will walk you through the high-level process of designing a machine.
-At the end of each step of the guide, you'll learn how to apply the step to a fictional example project: the **wood sanding project**.
-
-The following steps will teach you _how to approach_ building machines.
-If you are looking to build your first example machine, we recommend you follow the [Desk Safari Tutorial](/operate/hello-world/tutorial-desk-safari/).
-
-## Step 1: Identify the building blocks
-
-When building a project, it's easiest to start by identifying the hardware and software you know you will need.
-This will help you determine the main building blocks of your project.
-
-{{< table >}}
-{{< tablestep start=1 >}}
-
-<p><strong>Consider the hardware you need.</strong></p>
-<p>In Viam, hardware components are <em>components</em>.
-To start with the minimum amount of hardware, begin with one robotic arm, one end effector, and one camera.</p>
-<p>Review the following list of components and consider which components you may need. If in doubt, click on the component to review its API to understand what the component does.</p>
-
-{{< cards >}}
-{{% relatedcard link="/reference/apis/components/arm/" highlight="green" %}}
-{{% relatedcard link="/reference/apis/components/base/" %}}
-{{% relatedcard link="/reference/apis/components/board/" %}}
-{{% relatedcard link="/reference/apis/components/button/" %}}
-{{% relatedcard link="/reference/apis/components/camera/" highlight="green" %}}
-{{% relatedcard link="/reference/apis/components/encoder/" %}}
-{{% relatedcard link="/reference/apis/components/gantry/" %}}
-{{% relatedcard link="/reference/apis/components/generic/" %}}
-{{% relatedcard link="/reference/apis/components/gripper/" highlight="green" %}}
-{{% relatedcard link="/reference/apis/components/input-controller/" %}}
-{{% relatedcard link="/reference/apis/components/motor/" %}}
-{{% relatedcard link="/reference/apis/components/movement-sensor/" %}}
-{{% relatedcard link="/reference/apis/components/power-sensor/" %}}
-{{% relatedcard link="/reference/apis/components/sensor/" %}}
-{{% relatedcard link="/reference/apis/components/servo/" %}}
-{{% relatedcard link="/reference/apis/components/switch/" %}}
-{{< /cards >}}
-
-<p><b>Wood sanding project:</b>
-Imagine you are building a project to sand wood.
-You want to use one or more robotic arms to do the sanding, and cameras or possibly LiDAR to identify where to sand.</p>
-
-<p>The hardware needs for the sanding project can be translated into the following components:</p>
-<ul>
-<li>one arm</li>
-<li>one gripper for the end effector</li>
-<li>one camera</li>
-</ul>
-
-<p>That covers the hardware for the project.</p>
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Consider other components you need.**
-
-Each piece of hardware in a project is a component, but not every component represents a piece of hardware.
-Sometimes a component is just software that uses the same API endpoints as a physical component might.
-
-**Wood sanding project:** Let's say you also want a button to start and stop sanding.
-You don't need to decide at this point whether the button is physical or software.
-For now, let's just add a button component to the list of components for the project.
-
-{{% /tablestep %}}
-{{< tablestep >}}
-
-<p><strong>Consider the services you need.</strong></p>
-<p>While components mostly operate hardware, <em>services</em> do more complex work such as motion planning or machine learning.
-Services often operate on components.</p>
-<p>Review the following list of services and consider which services you may need. If in doubt, click on the service to review its API to understand what the service does.</p>
-
-{{< cards >}}
-{{% relatedcard link="/reference/apis/services/data/" %}}
-{{% relatedcard link="/reference/apis/services/ml/" highlight="green" %}}
-{{% relatedcard link="/reference/apis/services/vision/" highlight="green" %}}
-{{% relatedcard link="/reference/apis/services/motion/" highlight="green" %}}
-{{% relatedcard link="/reference/apis/services/navigation/" %}}
-{{% relatedcard link="/reference/apis/services/slam/" %}}
-{{% relatedcard link="/reference/apis/services/generic/" %}}
-{{% relatedcard link="/reference/apis/services/base-rc/" %}}
-{{< /cards >}}
-
-<p><strong>Wood sanding project:</strong> For the software side, you'll want something to identify the areas to sand.
-A common technique for sanding is to draw or write something on a piece of wood and then sand until you can no longer see the pencil marks.
-
-To identify where to sand, you can use a vision service that can detect the color of the pencil marks.
-Many vision services use a machine learning model, so we may need one as well to support the vision service in identifying where to sand.
-
-For moving the arm, you can use the motion service.</p>
-
-{{% /tablestep %}}
-{{< /table >}}
-
-At this point you have identified the main building blocks you need for your project.
-In the next step, you'll turn the list of building blocks you need into a minimal prototype.
-
-## Step 2: Start with a minimal prototype
-
-The next step is to build a prototype of your project using hardware and mock components.
-
-Let's consider the arm component.
-All arms use the same component API, which means you can call methods like `MoveToPosition()` on any arm component.
-
-Because of this, you can start by using hardware you already have or mock components.
-Then you can swap out for real or better hardware later as needed.
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Use available components.**
-
-There is a range of available models for each component.
-Check whether one of the available components works with your hardware, then configure and test it in the Viam web UI.
-
-If you cannot find a suitable component, skip the component for now.
-
-You can search all the available components in the Viam web UI when adding resources, or in the following expander.
-
-{{% expand "Click to view all available components" %}}
-
-{{< tabs >}}
-{{% tab name="All components" %}}
-
-{{<resources api="rdk:component" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Arm" %}}
-
-The following models implement the [arm component API](/reference/apis/components/arm/):
-
-{{<resources api="rdk:component:arm" type="arm" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Base" %}}
-
-The following models implement the [base component API](/reference/apis/components/base/):
-
-{{<resources api="rdk:component:base" type="base" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Board" %}}
-
-The following models implement the [board component API](/reference/apis/components/board/):
-
-{{<resources api="rdk:component:board" type="board" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Button" %}}
-
-The following models implement the [button component API](/reference/apis/components/button/):
-
-{{<resources api="rdk:component:button" type="button" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Camera" %}}
-
-The following models implement the [camera component API](/reference/apis/components/camera/):
-
-{{<resources api="rdk:component:camera" type="camera" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Encoder" %}}
-
-The following models implement the [encoder component API](/reference/apis/components/encoder/):
-
-{{<resources api="rdk:component:encoder" type="encoder" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Gantry" %}}
-
-The following models implement the [gantry component API](/reference/apis/components/gantry/):
-
-{{<resources api="rdk:component:gantry" type="gantry" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Generic" %}}
-
-The following models implement the [generic component API](/reference/apis/components/generic/):
-
-{{<resources api="rdk:component:generic" type="generic" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Gripper" %}}
-
-The following models implement the [gripper component API](/reference/apis/components/gripper/):
-
-{{<resources api="rdk:component:gripper" type="gripper" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Input Controller" %}}
-
-The following models implement the [input controller component API](/reference/apis/components/input-controller/):
-
-{{<resources api="rdk:component:input_controller" type="input_controller" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Motor" %}}
-
-The following models implement the [motor component API](/reference/apis/components/motor/):
-
-{{<resources api="rdk:component:motor" type="motor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Movement Sensor" %}}
-
-The following models implement the [movement sensor component API](/reference/apis/components/movement-sensor/):
-
-{{<resources api="rdk:component:movement_sensor" type="movement_sensor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Power Sensor" %}}
-
-The following models implement the [power sensor component API](/reference/apis/components/power-sensor/):
-
-{{<resources api="rdk:component:power_sensor" type="power_sensor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Sensor" %}}
-
-The following models implement the [sensor component API](/reference/apis/components/sensor/):
-
-{{<resources api="rdk:component:sensor" type="sensor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Servo" %}}
-
-The following models implement the [servo component API](/reference/apis/components/servo/):
-
-{{<resources api="rdk:component:servo" type="servo" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Switch" %}}
-
-The following models implement the [switch component API](/reference/apis/components/switch/):
-
-{{<resources api="rdk:component:switch" type="switch" no-intro="true">}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% alert title="Support notice" color="note" %}}
-Only modules marked as "built-in" or starting with `viam:` are officially supported and maintained by Viam.
-{{% /alert %}}
-
-{{% /expand %}}
-
-**Wood sanding project:**
-You might start with a `webcam` camera component and any webcam you have that works with your computer.
-Assuming you don't have a robotic arm and button at hand, let's configure those as mock resources in the next step.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Use mock resources.**
-
-If you cannot find a model that supports your specific hardware, start with the `fake` model for that component.
-The `fake` model is a mock model for testing that provides the same UI as real physical components.
-
-More importantly, it exposes the same API methods and returns mock data for testing.
-
-**Wood sanding project:**
-To mock the resources you don't have hardware for or which you can't find existing resource models for, you add a `fake` arm and a `fake` button.
-
-{{< imgproc src="/tutorials/building/control-tab.png" class="imgzoom shadow" alt="A machine control tab with a fake component" resize="1000x" >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Use available services.**
-
-{{< glossary_tooltip term_id="service" text="Services" >}} often require more knowledge and setup.
-We recommend consulting the docs for each service that might be helpful for your project and checking for suitable models and usage information.
-Then configure the service and test it.
-
-- [**Data management**](/data/capture-sync/capture-and-sync-data/): Capture, store, and sync data
-- [**Vision**](/vision/object-detection/detect/#using-a-vision-service) and [**ML model**](/vision/configure/): Detect objects, classify images, or track movement in camera streams
-- [**Motion**](/motion-planning/) and [**Frame system**](/motion-planning/frame-system/): Plan and execute complex movements
-- [**Navigation**](/operate/reference/services/navigation/): Help machines move autonomously
-- [**SLAM (Simultaneous Localization and Mapping)**](/operate/reference/services/slam/): Create maps of surroundings and locate machines within those maps
-- [**Generic**](/operate/reference/services/generic/): Perform custom business logic by periodically repeating tasks
-
-If you cannot find suitable services, skip the service for now.
-
-You can search all the available services in the Viam web UI when adding resources.
-
-**Wood sanding project:** To find a suitable vision service, you'd look through the available vision services.
-There is a [`color_detector` vision service](/reference/services/vision/color_detector/) which you could use to detect the pencil color on wood.
-You could also look for or create a machine learning model that recognizes drawings on wood.
-
-The motion service is built in.
-To use it you would follow the motion service docs to set it up with your arm.
-
-{{% /tablestep %}}
-{{< /table >}}
-
-With your prototype setup and each resource tested in isolation, you can now start writing the control logic that pulls everything together.
-
-## Step 3: Add your control logic
-
-To write your control logic, you'll create a module with a resource that will access and control your components and services.
-Often, people use the `DoCommand` method for control logic and then use a {{< glossary_tooltip term_id="job" text="job" >}} to repeatedly call the `DoCommand` method to execute the logic.
-
-For a step-by-step guide, see [Run control logic](/operate/modules/write-a-logic-module/).
-
-**Wood sanding project:**
-The control logic for the project might look like this:
-
-```python {class="line-numbers linkable-line-numbers" data-line=""}
-async def _sand_at(motion, world_state, arm, x_min, x_max, y_min, y_max):
-    # simple sanding logic that moves the arm from x_min, y_min to x_max, y_max
-    start_pose = translate_x_y_to_coord(x_min, y_min)
-    end_pose = translate_x_y_to_coord(x_max, y_max)
-    await motion.move(
-        component_name=arm, destination=start_pose, world_state=world_state)
-    await motion.move(
-        component_name=arm, destination=end_pose, world_state=world_state)
-    return True
-
-
-async def _on_loop(self):
-    self.logger.info("Executing control logic")
-    # Check vision service for detections of the color of the pencil markings
-    # on the wood
-    detections = self.vision_service.get_detections_from_camera(
-        self.camera_name)
-
-    for d in detections:
-        await _sand_at(
-            self.motion_service,
-            self.world_state,
-            self.arm_name,
-            d.x_min_normalized,
-            d.x_max_normalized,
-            d.y_min_normalized,
-            d.y_max_normalized
-        )
-
-
-async def do_command(
-    self,
-    command: Mapping[str, ValueTypes],
-    *,
-    timeout: Optional[float] = None,
-    **kwargs
-) -> Mapping[str, ValueTypes]:
-    result = {key: False for key in command.keys()}
-    for name, args in command.items():
-        if name == "action" and args == "run_control_logic":
-            await self._on_loop()
-            result[name] = True
-    return result
-```
-
-This logic needs iteration.
-The next step is to keep iterating to get closer to a working prototype.
-
-## Step 4: Test and Iterate
-
-As you test and iterate, you should also swap out any mock resources you have been using.
-If you find any hardware needs to be different, you can also change the hardware.
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Swap mock resources.**
-
-If there is no existing resource that suits your needs and you used `fake` resources, you need to create modules to implement your custom components or services.
-Often you can do this by wrapping an existing library.
-See [Create a module](/operate/modules/write-a-driver-module/) for more information.
-
-**Wood sanding project:**
-At this point, you would write a module for the button to start and stop sanding and integrate it with your control logic.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Swap hardware components.**
-
-The engineering cost of changing hardware is relatively low, due to the standardized API.
-If you change a component, you will need to change the model and configuration.
-Crucially, you should not need to update your control logic unless you use non-standardized `DoCommand` methods.
-If you do use `DoCommand` methods, you may need to update or wrap them.
-
-**Wood sanding project:**
-At this point in the project you should be getting an idea of the feasibility of the project.
-Since arms can be expensive, you may consider buying a cheap model first for testing.
-If the cheaper arm can't do sanding, you might test wiping drawings on a whiteboard.
-Once you're ready to invest, you can swap to a different arm model.
-
-You might also want to consider adding LiDAR.
-With a webcam, you can identify where to sand in a 2-dimensional space but arms move in 3D space.
-This means you might need to manually control the third coordinate for now.
-This may be fine depending on the use case, or you may consider adding LiDAR to measure the distance to the object being sanded.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Swap services.**
-
-Similar to swapping hardware, you can also swap services.
-Maybe you have more powerful hardware and now want to run a TensorFlow model instead of a TensorFlow Lite model.
-You can change the ML model service, the model, and the vision service by removing the old services and adding the new services with the same name.
-Again, you should not need to update your control logic unless you use non-standardized `DoCommand` methods.
-If you do use `DoCommand` methods, you may need to update or wrap them.
-
-**Wood sanding project:**
-This is where you'd probably test whether the `color_detector` vision service is sufficient for the project.
-If not, you might need to swap it for another vision service.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Manage resource configurations efficiently.**
-
-As you iterate, you may find that you want to save configurations of resources for future use or for reuse across different machines.
-Fragments are reusable configuration blocks that make tasks like switching between different resources or adding a configured resource to different machines easier.
-
-To view and create fragments, see the [**FRAGMENTS**](https://app.viam.com/fragments) tab.
-
-**Wood sanding project:**
-Your arm configurations are likely to have a lot of parameters that configure where your arm is in 3D space.
-If you want to try different arms, or use the arm for a different project, we recommend saving the reusable blocks of the configuration as fragments.
-
-{{% /tablestep %}}
-{{< /table >}}
-
-At this point your project should be mostly functional.
-However, you may find that as you move from a minimum viable prototype to a real-world product, you need additional resources.
-
-## Step 5: Consider resource constraints and scaling
-
-You can use {{< glossary_tooltip term_id="part" text="parts" >}} to chain multiple computers together to build complex machines with Viam.
-
-If you are dealing with resource constraints or need to use a specific operating system for some hardware or software, you can add sub-parts to your machine.
-
-If your project requires multiple machines to collaborate, you can use a remote part to share certain resources across the different machines, such as a camera that provides an overview for all machines.
-
-**Wood sanding project:**
-If you want multiple arms for the sanding project, you may require multiple computers to drive the arms.
-In that case, you can set them up as sub-parts.
-
-Read [Machine architecture: Parts](/operate/reference/architecture/parts/) for more information.
-
-You will likely continue to iterate and fine-tune your machine's logic and configuration.
-As you do that you may find a UI useful.
-
-## Step 6: Build a UI
-
-Most projects benefit from a UI, even if just to adjust settings.
-Viam provides SDKs for creating web and mobile applications.
-
-You can deploy a static web application as a [Viam application](/operate/control/viam-applications/), where Viam manages hosting infrastructure and authentication for you.
-
-**Wood sanding project:**
-You might consider a UI that shows the webcam's view of the surface to be sanded, as well as information about the motion plan for sanding.
-If you decide to start and stop sanding with the UI, this is also where you might call the button from.
-
-Your project is now a working prototype.
-In the next step, you'll learn about a few tools to consider to take your prototype to production.
-
-## Step 7: Scaling and production
-
-If you intend to ship machines, Viam provides the following features:
-
-- [**Provisioning**](/manage/fleet/provision/setup/): ship machines with a preconfigured setup so customers can connect them to the internet and get them up and running
-- [**Remote monitoring**](/manage/troubleshoot/monitor/): monitor, operate, and troubleshoot machines from anywhere in the world
-- [**Machine settings**](/manage/fleet/system-settings/): manage operating system package updates, network configuration, and system-level logging
-- [**Billing**](/organization/white-labeled-billing/): bill customers for usage through the Viam platform
-
-**Wood sanding project:**
-A sanding project might be bespoke enough that you will install it for your customers, so you may not require provisioning.
-
-Remote monitoring means you will be able to check on your clients' machines, perform updates, and troubleshoot should they need help.
-
-You probably do want to configure operating system package updates to ensure the machines update as you expect them to.
-
-The billing setup might be to charge end-customers a fixed cost per machine alongside usage cost.
-
-With this knowledge, you can take your machines from prototype to production.
-
-## Next steps
-
-Now you know how to build any machine, at least in theory.
-If you are ready to put the theory into practice, get started and [Set up a computer or SBC](/operate/install/setup/).
diff --git a/docs/operate/hello-world/first-project/_index.md b/docs/operate/hello-world/first-project/_index.md
deleted file mode 100644
index cd98053ff3..0000000000
--- a/docs/operate/hello-world/first-project/_index.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-linkTitle: "Your First Project"
-title: "Your First Project"
-weight: 17
-layout: "docs"
-type: "docs"
-no_list: true
-description: "Build a complete quality inspection system with Viam—from camera setup to customer-facing product."
-date: "2025-01-30"
----
-
-**Time:** ~45 minutes
-
-## Before You Begin
-
-### What is Viam?
-
-Viam lets you build robotics applications the way you build other software. Viam abstracts away hardware concerns and services for common tasks to enable you to focus on your core robotics application. Declare your hardware in a config, write control logic against well-defined APIs for everything, push updates through a CLI. Viam is the development workflow you're used to, applied to physical machines.
-
-Viam supports most robotics hardware. If your hardware isn't on the list, you can add support with a custom module by implementing the appropriate API.
-
-This tutorial uses the simplest work cell (camera + compute) to teach patterns that apply to _all_ Viam applications.
-
-## Scenario
-
-You're building a **quality inspection station** for a canning line. Cans move past a camera on a conveyor belt. Your system must:
-
-1. Detect when a can is present
-2. Classify it as PASS or FAIL (identifying dented cans)
-3. Log results for review and analysis
-4. Provide a monitoring dashboard for operators
-
-### Tutorial Overview
-
-In this tutorial you will work through a series of tasks that are common to many robotics applications. The techniques you learn here are applicable regardless of what hardware, software, data, or machine learning models you are working with.
-
-| Part                               | Time    | What You'll Do                                         |
-| ---------------------------------- | ------- | ------------------------------------------------------ |
-| [Part 1: Vision Pipeline](part-1/) | ~10 min | Set up camera, ML model, and vision service            |
-| [Part 2: Data Capture](part-2/)    | ~5 min  | Configure automatic image capture and cloud sync       |
-| [Part 3: Control Logic](part-3/)   | ~10 min | Generate module, write inspection logic, test from CLI |
-| [Part 4: Deploy a Module](part-4/) | ~10 min | Deploy module, configure detection data capture        |
-| [Part 5: Productize](part-5/)      | ~10 min | Build monitoring dashboard with Teleop                 |
-
-{{< expand "Full Section Outline" >}}
-
-**[Part 1: Vision Pipeline](part-1/)** (~15 min)
-
-- [1.1 Find Your Machine Part](part-1/#11-find-your-machine-part)
-- [1.2 Configure the Camera](part-1/#12-configure-the-camera)
-- [1.3 Test the Camera](part-1/#13-test-the-camera)
-- [1.4 Add an ML Model Service](part-1/#14-add-an-ml-model-service)
-- [1.5 Add a Vision Service](part-1/#15-add-a-vision-service)
-
-**[Part 2: Data Capture](part-2/)** (~10 min)
-
-- [2.1 Configure Data Capture](part-2/#21-configure-data-capture)
-- [2.2 View Captured Data](part-2/#22-view-captured-data)
-- [2.3 Summary](part-2/#23-summary)
-
-**[Part 3: Control Logic](part-3/)** (~15 min)
-
-- [3.1 Generate the Module Scaffolding](part-3/#31-generate-the-module-scaffolding)
-- [3.2 Add Remote Machine Connection](part-3/#32-add-remote-machine-connection)
-- [3.3 Add Detection Logic](part-3/#33-add-detection-logic)
-- [3.4 Summary](part-3/#34-summary)
-
-**[Part 4: Deploy a Module](part-4/)** (~10 min)
-
-- [4.1 Review the Generated Module Structure](part-4/#41-review-the-generated-module-structure)
-- [4.2 Build and Upload Your Module](part-4/#42-build-and-upload-your-module)
-- [4.3 Add the Module to Your Machine](part-4/#43-add-the-module-to-your-machine)
-- [4.4 Configure Detection Data Capture](part-4/#44-configure-detection-data-capture)
-- [4.5 Summary](part-4/#45-summary)
-
-**[Part 5: Productize](part-5/)** (~10 min)
-
-- [5.1 Create a Workspace](part-5/#51-create-a-workspace)
-- [5.2 Add a Camera Stream Widget](part-5/#52-add-a-camera-stream-widget)
-- [5.3 Add a Defects Per Minute Widget](part-5/#53-add-a-defects-per-minute-widget)
-- [5.4 Add a Confidence Trend Widget](part-5/#54-add-a-confidence-trend-widget)
-- [5.5 Arrange Your Dashboard](part-5/#55-arrange-your-dashboard)
-- [5.6 Summary](part-5/#56-summary)
-
-{{< /expand >}}
-
-## Get Started
-
-**[Begin Part 1: Vision Pipeline →](part-1/)**
diff --git a/docs/operate/hello-world/first-project/part-1.md b/docs/operate/hello-world/first-project/part-1.md
deleted file mode 100644
index f51a87573b..0000000000
--- a/docs/operate/hello-world/first-project/part-1.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-linkTitle: "Part 1: Vision Pipeline"
-title: "Part 1: Vision Pipeline"
-weight: 10
-layout: "docs"
-type: "docs"
-description: "Set up a camera, ML model, and vision service to detect defects."
-date: "2025-01-30"
----
-
-**Goal:** Get a computer vision pipeline working.
-
-**Skills:** Connect a machine to Viam, configure components in the Viam UI, configure services in the Viam UI.
-
-**Time:** ~15 min
-
-## Prerequisites
-
-Before starting this tutorial, you need the can inspection simulation running.
-Follow the **[Simulation Setup Guide](../sim-setup/)** to:
-
-1. Boot a simulation environment on Viam's cloud
-2. Create a machine in Viam and get credentials
-3. Start the container with your Viam credentials
-
-Once you see "Can Inspection Simulation Running!" in the container logs and your machine shows **Live** in the Viam app, return here to continue.
-
-{{< alert title="What you're working with" color="info" >}}
-The simulation runs Gazebo Harmonic inside a sandbox.
-It simulates a conveyor belt with cans (some dented) passing under an inspection camera.
-viam-server runs inside the sandbox and connects to Viam's cloud, just like it would on a physical machine.
-Everything you configure in the Viam app applies to the simulated hardware.
-{{< /alert >}}
-
-## 1.1 Find Your Machine Part
-
-In the Viam app, make sure the **Configure** tab for your machine is selected.
-
-{{<imgproc src="/tutorials/first-project/machine-live-status.png" resize="x1100" declaredimensions=true alt="Machine page showing the green Live status indicator next to the machine name." class="imgzoom shadow">}}
-
-Your machine is online but empty.
-To configure it, you'll add components and services to your **machine part**.
-A machine part is the compute hardware for your robot.
-In this tutorial, your machine part is a virtual machine running Linux in the Docker container.
-
-Find `inspection-station-1-main` in the **Configure** tab.
-
-## 1.2 Configure the Camera
-
-You'll now add the camera as a _component_.
-
-{{< expand "What's a component?" >}}
-In Viam, a **component** is any piece of hardware: cameras, motors, arms, sensors, grippers.
-You configure components by declaring what they are, and Viam handles the drivers and communication.
-
-**The power of Viam's component model:** All cameras expose the same API—USB webcams, Raspberry Pi camera modules, IP cameras, simulated cameras.
-Your application code uses the same `GetImages()` method regardless of the underlying hardware.
-Swap hardware by changing configuration, not code.
-{{< /expand >}}
-
-### Add a camera component
-
-To add the camera component to your machine part:
-
-1. Click the **+** button and select **Configuration block**
-2. Search for `gz-camera`
-3. Select `gz-camera:rgb-camera`
-4. Click **Add component**
-5. Enter `inspection-cam` for the name
-6. Click **Add component**
-
-{{<imgproc src="/tutorials/first-project/camera-config-panel.png" resize="x1100" declaredimensions=true alt="Camera configuration panel showing the inspection-cam component with JSON configuration section and documentation." class="imgzoom shadow">}}
-
-### Configure the camera
-
-To configure your camera component to work with the camera in the simulation, you need to specify the correct camera ID.
-Most components require a few configuration parameters.
-
-1. In the **JSON Configuration** section, add:
-
-   ```json
-   {
-     "id": "/inspection_camera"
-   }
-   ```
-
-2. Click **Save** in the top right
-
-{{<imgproc src="/tutorials/first-project/camera-config-json.png" resize="x1100" declaredimensions=true alt="Camera configuration panel with the JSON configuration set to inspection_camera." class="imgzoom shadow">}}
-
-{{< alert title="What happened behind the scenes" color="info" >}}
-You declared "this machine has an attached camera called `inspection-cam`" by editing the configuration in the Viam app.
-When you clicked **Save**, `viam-server` loaded the camera module which implements the camera API for the specific model of camera we are using.
-It also added a camera component, and made the camera available through Viam's standard camera API.
-Software you write, other services, and user interface components will use the API to get the images they need.
-Using the API as an abstraction means that everything still works if you swap cameras.
-{{< /alert >}}
-
-## 1.3 Test the Camera
-
-Verify the camera is working.
-Every component in Viam has a built-in test card right in the configuration view.
-
-### Open the test panel
-
-1. You should still be on the **Configure** tab with your `inspection-cam` selected
-2. Look for the **Test** section at the bottom of the camera's configuration panel
-3. Click **Test** to expand the camera's test card
-
-The camera component test card uses the camera API to add an image feed to the Viam app, enabling you to determine whether your camera is working.
-You should see a live video feed from the simulated camera.
-This is an overhead view of the conveyor/staging area.
-
-{{<imgproc src="/tutorials/first-project/camera-test-panel.png" resize="x1100" declaredimensions=true alt="Camera test panel showing a live video feed from the simulated inspection camera." class="imgzoom shadow">}}
-
-{{< alert title="Checkpoint" color="success" >}}
-Your camera is working.
-You can stream video and capture images from the simulated inspection station.
-{{< /alert >}}
-
-## 1.4 Add an ML Model Service
-
-Now you'll add machine learning to run inference on your camera feed.
-You'll configure two services:
-
-- **ML model service**—Loads a trained model for the inference task
-- **Vision service**—Connects the camera to the ML model and returns detections
-
-### Create the ML model service
-
-1. Click **+** next to your machine part
-2. Select **Configuration block**
-3. Search for `tflite`
-4. Select `tflite_cpu/tflite_cpu`
-5. Click **Add component**
-6. Name it `model-service`
-7. Click **Add component**
-
-{{<imgproc src="/tutorials/first-project/model-service-config.png" resize="x1100" declaredimensions=true alt="ML model service configuration panel showing the model-service with Select model button and TFLite CPU module." class="imgzoom shadow">}}
-
-### Select a model from the registry
-
-Configure the `model-service` ML model service you just included in your configuration.
-
-1. In the `model-service` configuration panel, click **Select model**
-2. Search for `can-defect-detection` and select it from the list (a model that classifies cans as PASS or FAIL based on defect detection)
-
-   {{<imgproc src="/tutorials/first-project/select-model-dialog.png" resize="x1100" declaredimensions=true alt="Select a model dialog showing the can-defect-detection model by Viam." class="imgzoom shadow">}}
-
-3. Click **Choose** to save the model selection
-4. Click **Save** in the upper right corner to save your configuration
-
-{{< alert title="Your own models" color="tip" >}}
-For a different application, you'd train a model on your specific data and upload it to the registry.
-The registry handles versioning and deployment of ML models across your fleet.
-{{< /alert >}}
-
-## 1.5 Add a Vision Service
-
-Now add a vision service that connects your camera to the ML model service.
-
-### Create the vision service
-
-1. Click **+** next to your machine part
-2. Select **Configuration block**
-3. Search for `vision`
-4. Select **mlmodel**
-5. Click **Add component**
-6. Name it `vision-service`
-7. Click **Add component**
-
-{{<imgproc src="/tutorials/first-project/vision-service-created.png" resize="x1100" declaredimensions=true alt="Vision service configuration panel showing the newly created vision-service with empty ML Model and Default Camera dropdowns." class="imgzoom shadow">}}
-
-### Link the camera and model in the vision service
-
-1. Select the `vision-service` service in your machine's configuration
-2. Find the **ML Model** dropdown and select `model-service` (the ML model service you just created)
-3. Find the **Default Camera** dropdown and select `inspection-cam`
-4. In the **Attributes** section, set **Minimum confidence threshold** to 0.75
-5. Click **Save** in the upper right corner
-
-{{<imgproc src="/tutorials/first-project/vision-service-config.png" resize="x1100" declaredimensions=true alt="Vision service configuration panel showing ML Model set to model-service, Default Camera set to inspection-cam, and confidence threshold at 0.75." class="imgzoom shadow">}}
-
-### Test the vision service
-
-1. Find the **Test** section at the bottom of the `vision-service` configuration panel
-2. Expand the **Test** card
-3. If not already selected, select `inspection-cam` as the camera source
-4. Set **Detections/Classifications** to `Live`
-5. Check that detection and labeling are working
-
-{{<imgproc src="/tutorials/first-project/vision-service-test.png" resize="x1100" declaredimensions=true alt="Vision service test panel showing a can detected with a bounding box and FAIL label." class="imgzoom shadow">}}
-
-{{< alert title="Checkpoint" color="success" >}}
-You've configured a complete ML inference pipeline that can detect defective cans.
-
-The ML model service loads a trained model and exposes an `Infer()` method, while the vision service handles the rest—grabbing images from the camera, running them through the model, and returning structured detections with bounding boxes, labels, and confidence scores.
-
-This pattern works for any ML task.
-Swap the model for object detection, classification, or segmentation without changing the pipeline.
-You can also swap one camera for another with one configuration change.
-
-Next, you'll set up continuous data capture so every detection is recorded and queryable.
-{{< /alert >}}
-
-**[Continue to Part 2: Data Capture →](../part-2/)**
diff --git a/docs/operate/hello-world/first-project/part-2.md b/docs/operate/hello-world/first-project/part-2.md
deleted file mode 100644
index ca3c5d635d..0000000000
--- a/docs/operate/hello-world/first-project/part-2.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-linkTitle: "Part 2: Data Capture"
-title: "Part 2: Data Capture"
-weight: 20
-layout: "docs"
-type: "docs"
-description: "Configure automatic image capture and cloud sync for your inspection system."
-date: "2025-01-30"
----
-
-**Goal:** Configure and use a machine-to-cloud data capture pipeline.
-
-**Skills:** Data capture configuration, cloud sync, browsing captured data.
-
-**Time:** ~5 min
-
-For inspection applications such as this one, monitoring defect detection is important both to ensure production line health and product quality.
-You want to ensure the vision model is detecting a very high percentage of defects and quickly detect any problems.
-In addition, it's important to collect production training data to improve defect detection models over time.
-
-In this part of the tutorial, you'll configure continuous data capture to support these goals.
-To do this, you'll use Viam's built-in data capture and cloud sync.
-Once enabled, data capture services run automatically in the background.
-Data gets buffered locally, synced to the cloud at an interval you configure, and is then available for review in the Viam app.
-
-## 2.1 Configure Data Capture
-
-**Include the data service in your machine configuration:**
-
-1. Click **+** next to **inspection-station-1-main** in the **Configure** tab
-2. Click **Configuration block**
-3. Search for `data`
-4. Select **builtin** (this is the built-in **Data Manager** service)
-
-   {{<imgproc src="/tutorials/first-project/data-service-search.png" resize="x1100" declaredimensions=true alt="Configuration Blocks search dialog showing the builtin Data Manager service." class="imgzoom shadow">}}
-
-5. Click **Add component**
-6. Name it `data-service`
-7. Click **Add component**
-8. **Save** your updated machine configuration
-
-The default configuration options for the data service are correct for our application so we can move on to capturing data from the vision service.
-
-**Enable data capture on the vision service:**
-
-1. Click `vision-service` in your machine configuration
-2. Find the **Data capture** section and click **Add method**
-3. Select the method to capture: `CaptureAllFromCamera`
-4. Set **Frequency (hz)** to `0.5` (every 2 seconds)
-5. Set **Camera name** to `inspection-cam`
-6. **Save** your configuration
-
-**Verify it's working:**
-
-1. In the **Data capture** section of the `vision-service` configuration panel you should now see a collapsible component labeled **Latest capture** with a day and time specified
-2. Click on **Latest capture** and view the most recent image captured
-
-Your machine is now capturing detection results and images every 2 seconds and syncing them to the Viam cloud application.
-Once synced to the cloud, the data is removed from your machine to free up storage.
-
-{{<imgproc src="/tutorials/first-project/vision-data-capture.png" resize="x1100" declaredimensions=true alt="Vision service configuration showing data capture enabled with CaptureAllFromCamera method at 0.5 Hz." class="imgzoom shadow">}}
-
-{{< alert title="Tip" color="tip" >}}
-Click **JSON** in the Configure tab to see how data capture settings appear in the raw configuration.
-Each component and service with data capture enabled has a `service_configs` entry containing `capture_methods`.
-{{< /alert >}}
-
-## 2.2 View Captured Data
-
-Up to this point in the tutorial, you've focused on configuring your machine.
-To view the data you are now capturing, you will need to open the data user interface in Viam.
-Find the main Viam menu that includes: **Fleet**, **Data**, and **Registry** at the top of the page.
-Right click on **Data** to open in a separate tab.
-
-**View captured data:**
-
-1. Review the grid of images captured from your work cell
-2. Click on an image to see the detection results for that image
-3. Click on a few other images to see how detection results vary for cans labeled `PASS` versus `FAIL`
-
-   {{<imgproc src="/tutorials/first-project/data-tab-images.png" resize="x1100" declaredimensions=true alt="Data tab showing a grid of captured images from the inspection camera." class="imgzoom shadow">}}
-
-   This captured data serves multiple purposes:
-
-   - **Compliance**—Auditable record of every inspection
-   - **Quality trends**—"FAIL rate increased 20% this week"
-   - **Model improvement**—Export images of cans to retrain your ML model
-   - **Incident review**—"Show me all FAILs from Tuesday's shift"
-
-## 2.3 Summary
-
-Data capture is now running in the background:
-
-- Captures images with detection overlays
-- Syncs to cloud automatically
-- Available for visual review and filtering
-
-This foundation records everything your vision pipeline sees.
-In Part 3, you'll write custom control logic to act on detections.
-Later, you'll configure tabular data capture to enable SQL queries on detection results.
-
-{{< alert title="Checkpoint" color="success" >}}
-Your system captures every detection as an image.
-Data syncs to the cloud where you can browse, filter, and review results.
-{{< /alert >}}
-
-**[Continue to Part 3: Control Logic →](../part-3/)**
diff --git a/docs/operate/hello-world/first-project/part-3.md b/docs/operate/hello-world/first-project/part-3.md
deleted file mode 100644
index aeebb03c74..0000000000
--- a/docs/operate/hello-world/first-project/part-3.md
+++ /dev/null
@@ -1,582 +0,0 @@
----
-linkTitle: "Part 3: Control Logic"
-title: "Part 3: Control Logic"
-weight: 30
-layout: "docs"
-type: "docs"
-description: "Write inspection logic that detects defective cans."
-date: "2025-01-30"
----
-
-**Goal:** Write inspection logic that detects defective cans.
-
-**Skills:** Generate module scaffolding using the Viam CLI, experiment with Viam SDKs, develop code iteratively against remote hardware
-
-**Time:** ~15 min
-
-## What You'll Build
-
-Your vision pipeline detects defective cans and records the results with images synced to the cloud. Now you'll write a module that calls the vision service and exposes detection results through `DoCommand`. This detection data can drive dashboards, alerts, or—in a production system—trigger actuators to reject defective cans.
-
-You'll use the **module-first development pattern**: write code on your laptop, test it against remote hardware over the network. This workflow lets you iterate quickly—edit code, run it, see results—without redeploying after every change.
-
-## Prerequisites
-
-This part of the tutorial requires the Go programming language and the Viam CLI.
-
-### Install Go
-
-Check your Go version:
-
-```bash
-go version
-```
-
-You need Go 1.21 or later. If Go isn't installed or is outdated, download it from [go.dev/dl](https://go.dev/dl/).
-
-### Install the Viam CLI
-
-The Viam CLI is used for authentication, module generation, and deployment.
-
-{{< tabs >}}
-{{% tab name="macOS" %}}
-
-```bash
-brew tap viamrobotics/brews
-brew install viam
-```
-
-{{% /tab %}}
-{{% tab name="Linux" %}}
-
-```bash
-sudo curl -o /usr/local/bin/viam https://storage.googleapis.com/packages.viam.com/apps/viam-cli/viam-cli-stable-linux-amd64
-sudo chmod +x /usr/local/bin/viam
-```
-
-{{% /tab %}}
-{{% tab name="Windows" %}}
-
-```powershell
-Invoke-WebRequest -Uri "https://storage.googleapis.com/packages.viam.com/apps/viam-cli/viam-cli-stable-windows-amd64.exe" -OutFile "viam.exe"
-```
-
-Then run as `.\viam.exe` or add the directory to your PATH.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Verify and Log In
-
-Verify the CLI is installed:
-
-```bash
-viam version
-```
-
-Log in to Viam:
-
-```bash
-viam login
-```
-
-This stores credentials that your code will use to connect to remote machines.
-
-{{< alert title="Note" color="info" >}}
-The Viam CLI (`viam`) is different from `viam-server`. The CLI runs on your development machine; `viam-server` runs on your robot/machine.
-{{< /alert >}}
-
-## 3.1 Generate the Module Scaffolding
-
-A **module** in Viam is a package of code that adds capabilities to a machine. Modules run alongside viam-server and can provide custom components (like a new type of sensor) or services (like our inspection logic). By packaging code as a module, you can deploy it to any machine, share it with others, and manage versions through the Viam registry.
-
-The Viam CLI can generate module boilerplate—saving you from writing registration code, build configuration, and project structure from scratch. This lets you focus on your business logic instead of infrastructure.
-
-**Set your organization's namespace:**
-
-Before creating a module, your organization needs a public namespace. This is a unique identifier used in module names (for example, `my-namespace:inspection-module`).
-
-1. Click the organization dropdown in the upper right corner of the Viam app next to your initials
-2. Select **Settings**
-3. Find **Public namespace** and enter a unique name (lowercase letters, numbers, hyphens)
-4. Click **Save**
-
-{{<imgproc src="/tutorials/first-project/org-settings-dropdown.png" resize="x1100" declaredimensions=true alt="Organization dropdown menu showing Settings option." class="imgzoom shadow">}}
-
-If your organization already has a namespace, you can skip this step.
-
-**Generate the module scaffolding:**
-
-```bash
-viam module generate
-```
-
-Enter these values when prompted:
-
-| Prompt                 | Value                      |
-| ---------------------- | -------------------------- |
-| Module name            | `inspection-module`        |
-| Language               | `Go`                       |
-| Visibility             | `Private`                  |
-| Namespace/Organization | _Select your organization_ |
-| Resource type          | `Generic Service`          |
-| Model name             | `inspector`                |
-| Register module        | `Yes`                      |
-
-**Why Generic Service?** Viam has built-in APIs for hardware (camera, motor, arm). When your logic doesn't fit those categories, Generic Service provides a flexible `DoCommand` interface—ideal for application-specific logic like inspection.
-
-**What does "Register module" do?** Creates an entry in the Viam registry (just metadata, not your code). This enables cloud deployment later.
-
-### Files You'll Work With
-
-The generator creates a complete module structure. You'll focus on three files:
-
-- **`module.go`**—Your service implementation. Contains Config, constructor, and methods. This is where your inspection logic goes.
-- **`cmd/cli/main.go`**—CLI for local testing. We'll modify this to connect to your remote machine so you can test against real hardware without deploying.
-- **`cmd/module/main.go`**—Entry point when deployed. Registers your service with viam-server. You won't modify this.
-
-This is the **module-first development pattern**: write logic in `module.go`, test locally with the CLI against your real machine, then deploy.
-
-## 3.2 Add Remote Machine Connection
-
-The generated CLI creates your service with empty dependencies—fine for testing logic in isolation, but useless for testing against real hardware. We'll modify it to connect to your remote machine and access its resources. With this approach to Viam application development, your code runs locally on your laptop, but it talks to real cameras and other hardware your machine configuration includes.
-
-Why is this valuable? Traditional embedded development requires: edit code → build → deploy → test → repeat. With module-first development: edit code → run locally → see results on real hardware. The iteration cycle drops from minutes to seconds.
-
-### Step 1: Connect to Your Machine
-
-The generated `realMain` function creates your inspector with empty dependencies—useful for testing in isolation, but it can't access your remote machine. We'll replace it with code that:
-
-- Accepts a `-host` flag for your machine's address
-- Uses your `viam login` credentials to authenticate
-- Establishes a secure connection to the remote machine
-
-Open `cmd/cli/main.go` and replace the import block with:
-
-```go
-import (
-    "context"
-    "flag"
-    "fmt"
-
-    "github.com/erh/vmodutils"
-    "go.viam.com/rdk/logging"
-)
-```
-
-Then replace the `realMain` function with:
-
-```go
-func realMain() error {
-    ctx := context.Background()
-    logger := logging.NewLogger("cli")
-
-    host := flag.String("host", "", "Machine address (required)")
-    flag.Parse()
-
-    if *host == "" {
-        return fmt.Errorf("need -host flag (get address from Viam app)")
-    }
-
-    logger.Infof("Connecting to %s...", *host)
-    machine, err := vmodutils.ConnectToHostFromCLIToken(ctx, *host, logger)
-    if err != nil {
-        return fmt.Errorf("failed to connect: %w", err)
-    }
-    defer machine.Close(ctx)
-
-    logger.Info("Connected successfully!")
-    return nil
-}
-```
-
-**Test the connection:**
-
-1. In the Viam app, go to your machine's **Configure** page
-2. Click the **Online** dropdown
-3. Click **Remote address** to copy your machine address
-
-   {{<imgproc src="/tutorials/first-project/machine-address.png" resize="x1100" declaredimensions=true alt="Live dropdown showing Remote address option with machine address visible." class="imgzoom shadow">}}
-
-4. ```bash
-   go run cmd/cli/main.go -host YOUR_MACHINE_ADDRESS
-   ```
-
-   You'll see WebRTC diagnostic output as the connection is established. Look for these messages confirming the connection:
-
-   ```text
-   Connecting to your-machine.abc123.viam.cloud...
-   ...
-   successfully (re)connected to remote at address
-   ...
-   Connected successfully!
-   ```
-
-   If you see an error, verify:
-
-   - Your machine is online (check the Viam app)
-   - You're logged in (`viam login`)
-   - The address is correct
-
-### Step 2: Access Remote Resources
-
-Now let's verify we can access the camera on the remote machine.
-
-**Add the camera import:**
-
-At the top of `cmd/cli/main.go`, add this import:
-
-```go
-"go.viam.com/rdk/components/camera"
-```
-
-**Fetch the camera dependencies:**
-
-```bash
-go mod tidy
-```
-
-**Add camera access after the connection:**
-
-After the `logger.Info("Connected successfully!")` line, add:
-
-```go
-// Get the camera from the remote machine
-cam, err := camera.FromProvider(machine, "inspection-cam")
-if err != nil {
-    return fmt.Errorf("failed to get camera: %w", err)
-}
-
-// Capture an image
-images, _, err := cam.Images(ctx, nil, nil)
-if err != nil {
-    return fmt.Errorf("failed to get images: %w", err)
-}
-
-if len(images) == 0 {
-    return fmt.Errorf("no images returned from camera")
-}
-
-logger.Infof("Got image from camera: %s", images[0].SourceName)
-```
-
-If your editor doesn't auto-format, run `gofmt -w cmd/cli/main.go` to fix indentation.
-
-**Test resource access:**
-
-```bash
-go mod tidy
-go run cmd/cli/main.go -host YOUR_MACHINE_ADDRESS
-```
-
-You'll see the same WebRTC diagnostic output, followed by the camera confirmation:
-
-```text
-Connected successfully!
-Got image from camera: inspection-cam
-```
-
-You've just accessed a camera on a remote machine from your local development environment. This same pattern works for any Viam resource—motors, sensors, vision services, or custom components.
-
-{{< alert title="Takeaway" color="tip" >}}
-The `vmodutils.ConnectToHostFromCLIToken` function uses your `viam login` credentials to establish a secure connection. Once connected, you access resources the same way you would in deployed code. This abstraction is what makes module-first development possible.
-{{< /alert >}}
-
-## 3.3 Add Detection Logic
-
-Now we'll implement the actual inspection logic. The generator created `module.go` with stub methods—we'll fill them in to call the vision service and process results.
-
-Complete all five steps below, then test at the end.
-
-{{< alert title="Concept: Dependency Injection" color="info" >}}
-Your inspector needs a vision service to detect cans. Rather than hardcoding how to find that service, you _declare_ the dependency in your Config, and Viam _injects_ it into your constructor. This means:
-
-- Your code doesn't know where resources live (local or remote)
-- The same code works in CLI testing and deployed modules
-  {{< /alert >}}
-
-### Step 1: Declare Dependencies
-
-The Config struct tells Viam what resources your inspector needs. The Validate method returns those resource names so Viam knows to inject them.
-
-Remember in Part 1 when you configured the camera with `"id": "/inspection_camera"`? When you add the service we're building now to your machine (in Part 4 of this tutorial), you'll configure it with attributes for the camera and vision service to use.
-
-The Config struct in the code below specifies what the names of those attributes will be in the configuration JSON you'll update after including this module in your machine config.
-
-In `module.go`, find the `Config` struct and `Validate` method and replace them with the code below.
-
-```go
-type Config struct {
-    Camera        string `json:"camera"`
-    VisionService string `json:"vision"`
-}
-
-func (cfg *Config) Validate(path string) ([]string, []string, error) {
-    if cfg.Camera == "" {
-        return nil, nil, fmt.Errorf("camera is required")
-    }
-    if cfg.VisionService == "" {
-        return nil, nil, fmt.Errorf("vision is required")
-    }
-    return []string{cfg.Camera, cfg.VisionService}, nil, nil
-}
-```
-
-The first return value from Validate lists dependencies—Viam ensures these resources exist before creating your service.
-
-### Step 2: Store Dependencies
-
-The generated struct needs a field to hold the vision service that Viam will inject.
-
-Find the `inspectionModuleInspector` struct in `module.go` and add a `detector` field:
-
-```go
-type inspectionModuleInspector struct {
-    resource.AlwaysRebuild
-
-    name   resource.Name
-    logger logging.Logger
-    cfg    *Config
-
-    cancelCtx  context.Context
-    cancelFunc func()
-
-    detector vision.Service  // Add this field
-}
-```
-
-The `detector` field will hold a reference to the vision service.
-
-Add the vision import to your import block:
-
-```go
-"go.viam.com/rdk/services/vision"
-```
-
-### Step 3: Wire Dependencies
-
-The constructor extracts the vision service from the dependencies map and stores it in the struct. This validates that the vision service exists on the machine and that methods on that struct in the module we're writing have access to it.
-
-Update `NewInspector` in `module.go`:
-
-```go
-func NewInspector(ctx context.Context, deps resource.Dependencies, name resource.Name, cfg *Config, logger logging.Logger) (resource.Resource, error) {
-    cancelCtx, cancelFunc := context.WithCancel(context.Background())
-
-    // --- Add this block ---
-    detector, err := vision.FromProvider(deps, cfg.VisionService)
-    if err != nil {
-        return nil, fmt.Errorf("failed to get vision service %q: %w", cfg.VisionService, err)
-    }
-    // --- End add ---
-
-    s := &inspectionModuleInspector{
-        name:       name,
-        logger:     logger,
-        cfg:        cfg,
-        cancelCtx:  cancelCtx,
-        cancelFunc: cancelFunc,
-        detector:   detector,  // Add this field
-    }
-    return s, nil
-}
-```
-
-`vision.FromProvider` looks up the resource by name and returns it as the correct type. If the resource doesn't exist or isn't a vision service, it returns an error.
-
-### Step 4: Add Detection Logic
-
-Now add the internal method that performs inspection, and update `DoCommand` to expose it.
-
-Add the `detect` method to `module.go` (lowercase—it's internal):
-
-```go
-func (s *inspectionModuleInspector) detect(ctx context.Context) (string, float64, error) {
-    detections, err := s.detector.DetectionsFromCamera(ctx, s.cfg.Camera, nil)
-    if err != nil {
-        return "", 0, err
-    }
-
-    if len(detections) == 0 {
-        return "NO_DETECTION", 0, nil
-    }
-
-    best := detections[0]
-    for _, det := range detections[1:] {
-        if det.Score() > best.Score() {
-            best = det
-        }
-    }
-
-    return best.Label(), best.Score(), nil
-}
-```
-
-`DetectionsFromCamera` tells the vision service which camera to use. The vision service grabs an image, runs the ML model, and returns structured detection results. We find the highest-confidence detection and return its label and score.
-
-Now update the generated `DoCommand` stub to dispatch to `detect`:
-
-```go
-func (s *inspectionModuleInspector) DoCommand(ctx context.Context, cmd map[string]interface{}) (map[string]interface{}, error) {
-    if _, ok := cmd["detect"]; ok {
-        label, confidence, err := s.detect(ctx)
-        if err != nil {
-            return nil, err
-        }
-        return map[string]interface{}{
-            "label":      label,
-            "confidence": confidence,
-        }, nil
-    }
-    return nil, fmt.Errorf("unknown command: %v", cmd)
-}
-```
-
-`DoCommand` is the public API for generic services. External callers pass a command map, and the method dispatches to internal logic. This pattern keeps implementation details private while exposing a flexible interface.
-
-### Step 5: Update the CLI
-
-Now wire everything together in `cmd/cli/main.go` so we can test. This replaces the camera test code from section 3.2.
-
-Replace the `realMain` function:
-
-```go
-func realMain() error {
-    ctx := context.Background()
-    logger := logging.NewLogger("cli")
-
-    host := flag.String("host", "", "Machine address (required)")
-    flag.Parse()
-
-    if *host == "" {
-        return fmt.Errorf("need -host flag (get address from Viam app)")
-    }
-
-    logger.Infof("Connecting to %s...", *host)
-    machine, err := vmodutils.ConnectToHostFromCLIToken(ctx, *host, logger)
-    if err != nil {
-        return fmt.Errorf("failed to connect: %w", err)
-    }
-    defer machine.Close(ctx)
-
-    cfg := &inspectionmodule.Config{
-        Camera:        "inspection-cam",
-        VisionService: "vision-service",
-    }
-
-    deps, err := vmodutils.MachineToDependencies(machine)
-    if err != nil {
-        return fmt.Errorf("failed to get dependencies: %w", err)
-    }
-
-    inspector, err := inspectionmodule.NewInspector(
-        ctx,
-        deps,
-        generic.Named("inspector"),
-        cfg,
-        logger,
-    )
-    if err != nil {
-        return fmt.Errorf("failed to create inspector: %w", err)
-    }
-
-    result, err := inspector.DoCommand(ctx, map[string]interface{}{"detect": true})
-    if err != nil {
-        return fmt.Errorf("detection failed: %w", err)
-    }
-
-    label := result["label"].(string)
-    confidence := result["confidence"].(float64)
-    logger.Infof("Detection: %s (%.1f%% confidence)", label, confidence*100)
-    return nil
-}
-```
-
-The CLI creates the inspector with dependencies from the remote machine, then calls `DoCommand` with `{"detect": true}`. This is the same pattern used in production Viam modules, where `DoCommand` is the public API for generic services.
-
-Update the imports:
-
-```go
-import (
-    "context"
-    "flag"
-    "fmt"
-
-    "inspectionmodule"
-    "github.com/erh/vmodutils"
-    "go.viam.com/rdk/logging"
-    "go.viam.com/rdk/services/generic"
-)
-```
-
-### Test Detection
-
-Fetch dependencies and run:
-
-```bash
-go mod tidy
-go run ./cmd/cli -host YOUR_MACHINE_ADDRESS
-```
-
-You should see:
-
-```text
-Connecting to your-machine-main.abc123.viam.cloud...
-Detection: PASS (94.2% confidence)
-```
-
-Run it several times—results change as different cans pass under the camera.
-
-{{< alert title="What just happened" color="info" >}}
-Your laptop connected to the remote machine, your code called the vision service, and the vision service ran ML inference on an image from the camera. The code runs locally but uses remote hardware—this is the module-first pattern in action.
-{{< /alert >}}
-
-{{< expand "Troubleshooting" >}}
-**"failed to connect" or timeout errors:**
-
-- Verify your machine is online in the Viam app
-- Check that you've run `viam login` successfully
-- Confirm the host address is correct
-
-**"failed to get vision service" error:**
-
-- Verify `vision-service` exists in your machine config (Part 1)
-- Check the exact name matches—it's case-sensitive
-
-**"NO_DETECTION" result:**
-
-- Normal if no can is in view—wait for one to appear
-- Check the camera is working in the Viam app's Test panel
-  {{< /expand >}}
-
-{{< alert title="Checkpoint" color="success" >}}
-You can now detect cans from your laptop. You declared dependencies in Config, returned them from Validate, and extracted them in the constructor. This pattern works for any Viam resource.
-{{< /alert >}}
-
-## 3.4 Summary
-
-You built a complete inspection system using the module-first development pattern:
-
-1. **Generated** the module scaffold—infrastructure handled, you focus on logic
-2. **Connected** to remote hardware from local code using vmodutils
-3. **Implemented detection** by calling the vision service and exposing results through `DoCommand`
-
-{{< alert title="Extending the inspector" color="tip" >}}
-In a production system, you could extend `DoCommand` to trigger actuators—for example, a motor that pushes defective cans off the belt. The same dependency injection pattern applies: declare the motor in Config, extract it in the constructor, and call it from your detection logic.
-{{< /alert >}}
-
-### What You Learned
-
-| Concept                      | What It Means                                         | Where You'll Use It                      |
-| ---------------------------- | ----------------------------------------------------- | ---------------------------------------- |
-| **Module-first development** | Test against real hardware without deploying          | Any time you're developing control logic |
-| **Dependency injection**     | Declare what you need, let Viam provide it            | Every module you build                   |
-| **DoCommand pattern**        | Expose functionality through a flexible map-based API | Any generic service                      |
-
-### The Key Insight
-
-Your inspector code doesn't know whether it's running from the CLI on your laptop or deployed as a module on the machine. It just uses the dependencies it's given. This abstraction is what makes rapid iteration possible during development and seamless deployment to production.
-
-**Your code is ready.** In Part 4, you'll deploy it to run on the machine and configure data capture for the detection results.
-
-**[Continue to Part 4: Deploy a Module →](../part-4/)**
diff --git a/docs/operate/hello-world/first-project/part-4.md b/docs/operate/hello-world/first-project/part-4.md
deleted file mode 100644
index eb49bd12b5..0000000000
--- a/docs/operate/hello-world/first-project/part-4.md
+++ /dev/null
@@ -1,405 +0,0 @@
----
-linkTitle: "Part 4: Deploy a Module"
-title: "Part 4: Deploy a Module"
-weight: 40
-layout: "docs"
-type: "docs"
-description: "Deploy your inspector module and configure queryable detection data capture."
-date: "2025-01-30"
----
-
-**Goal:** Deploy your inspector to run on the machine autonomously.
-
-**Skills:** Module packaging, registry deployment, tabular data capture.
-
-**Time:** ~10 min
-
-## What You'll Do
-
-In Part 3, you built inspection logic that runs from your laptop. That's great for development, but in production the code needs to run on the machine itself—so it works even when your laptop is closed.
-
-The module generator already created most of what you need:
-
-- `cmd/module/main.go`—module entry point
-- `meta.json`—registry metadata
-- Model registration in `init()`
-
-You just need to build, package, and deploy.
-
-## 4.1 Review the Generated Module Structure
-
-The generator already created everything needed to run as a module. Let's review what's there.
-
-**`cmd/module/main.go`**
-
-```go
-func main() {
-    module.ModularMain(
-        resource.APIModel{API: generic.API, Model: inspectionmodule.Inspector},
-    )
-}
-```
-
-This connects your module to viam-server and registers the inspector model. When you add this service to your machine configuration, viam-server uses this entry point to create and manage instances. You don't need to modify it.
-
-{{< alert title="What is a model?" color="info" >}}
-In Viam, a _model_ is a specific implementation of an API—identified by a triplet like `your-namespace:inspection-module:inspector`. This can be confusing because we also refer to ML models as "models." When you see "model" in the context of modules and resources, it means the implementation type, not a machine learning model.
-{{< /alert >}}
-
-**`module.go`** provides model registration in `init()`:
-
-The generator created an `init()` function that registers your model:
-
-```go
-var Inspector = resource.NewModel("your-namespace", "inspection-module", "inspector")
-
-func init() {
-    resource.RegisterService(generic.API, Inspector,
-        resource.Registration[resource.Resource, *Config]{
-            Constructor: newInspectionModuleInspector,
-        },
-    )
-}
-```
-
-Note the two uses of "inspector" here:
-
-- `Inspector` (capital I)—the Go variable name, exported so `main.go` can reference it
-- `"inspector"` (lowercase, in quotes)—a string that becomes the third part of the model triplet `your-namespace:inspection-module:inspector`
-
-This `init()` function runs automatically when the module starts, telling viam-server how to create instances of your service.
-
-**`meta.json`** Registry metadata:
-
-```json
-{
-  "module_id": "your-namespace:inspection-module",
-  "visibility": "private",
-  "models": [
-    {
-      "api": "rdk:service:generic",
-      "model": "your-namespace:inspection-module:inspector"
-    }
-  ],
-  "entrypoint": "bin/inspection-module"
-}
-```
-
-This tells the registry what your module provides.
-
-{{< alert title="The key pattern" color="tip" >}}
-The generator created module infrastructure. You added business logic (`detect`) and exposed it through `DoCommand`. The same `NewInspector` constructor works for both CLI testing and module deployment.
-{{< /alert >}}
-
-## 4.2 Build and Upload Your Module
-
-**Update the module's model list:**
-
-The module was already registered in the Viam registry when you ran `viam module generate` in Part 3 (you answered "Yes" to "Register module"). Now you need to update its model metadata. First, build a local binary:
-
-```bash
-make
-```
-
-Then run `update-models` to detect which models your module provides and update `meta.json`:
-
-```bash
-viam module update-models --binary /full/path/to/bin/inspection-module
-```
-
-Replace `/full/path/to/` with the absolute path to your module directory.
-
-**Cross-compile for the target platform:**
-
-Your module will run inside a Linux container, not on your development machine. Even if your Mac and the container both use ARM processors, a macOS binary won't run on Linux—you need to cross-compile. Cross-compilation also requires disabling CGO (Go's C interop) and using the `no_cgo` build tag.
-
-{{< tabs >}}
-{{% tab name="Mac (Apple Silicon)" %}}
-
-```bash
-CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -tags no_cgo -o bin/inspection-module ./cmd/module
-```
-
-{{% /tab %}}
-{{% tab name="Mac (Intel)" %}}
-
-```bash
-CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -tags no_cgo -o bin/inspection-module ./cmd/module
-```
-
-{{% /tab %}}
-{{% tab name="Windows" %}}
-
-```bash
-CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -tags no_cgo -o bin/inspection-module ./cmd/module
-```
-
-{{% /tab %}}
-{{% tab name="Linux (Intel/AMD)" %}}
-
-```bash
-go build -o bin/inspection-module ./cmd/module
-```
-
-No cross-compilation needed—you're already on Linux.
-
-{{% /tab %}}
-{{% tab name="Linux (ARM)" %}}
-
-```bash
-go build -o bin/inspection-module ./cmd/module
-```
-
-No cross-compilation needed—you're already on Linux.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-**Package for upload:**
-
-```bash
-tar czf module.tar.gz meta.json bin/
-```
-
-**Upload to the registry:**
-
-The `--platform` flag must match the architecture you compiled for:
-
-{{< tabs >}}
-{{% tab name="Mac (Apple Silicon)" %}}
-
-```bash
-viam module upload --version 0.0.1 --platform linux/arm64 --upload module.tar.gz
-```
-
-{{% /tab %}}
-{{% tab name="Mac (Intel)" %}}
-
-```bash
-viam module upload --version 0.0.1 --platform linux/amd64 --upload module.tar.gz
-```
-
-{{% /tab %}}
-{{% tab name="Windows" %}}
-
-```bash
-viam module upload --version 0.0.1 --platform linux/amd64 --upload module.tar.gz
-```
-
-{{% /tab %}}
-{{% tab name="Linux (Intel/AMD)" %}}
-
-```bash
-viam module upload --version 0.0.1 --platform linux/amd64 --upload module.tar.gz
-```
-
-{{% /tab %}}
-{{% tab name="Linux (ARM)" %}}
-
-```bash
-viam module upload --version 0.0.1 --platform linux/arm64 --upload module.tar.gz
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## 4.3 Add the Module to Your Machine
-
-**Add the inspector service:**
-
-1. In the Viam app, go to your machine's **Configure** tab
-2. Click **+** next to your machine part
-3. Select **Configuration block**
-4. Search for your model (for example, `your-namespace:inspection-module:inspector`)
-5. Name it `inspector-service`
-6. Click **Create**
-
-When you add a service from the registry, the module that provides it is added automatically.
-
-**Configure the service attributes:**
-
-```json
-{
-  "camera": "inspection-cam",
-  "vision": "vision-service"
-}
-```
-
-Click **Save**.
-
-**Verify it started:**
-
-1. Go to the **Logs** tab
-2. Look for startup messages from the inspector module
-3. You should see it initialize and connect to the camera and vision service
-
-**Test the inspector:**
-
-1. In the **Configure** tab, click on `inspector-service` to open its configuration panel
-2. Expand **Test** card at the bottom
-3. In the **DoCommand** field, enter `{"detect": true}`
-4. Click **Execute**
-5. You should see a response with `label` and `confidence` values
-6. Click **Execute** several more times to see different detections as cans pass beneath the inspection-cam
-
-{{<imgproc src="/tutorials/first-project/docommand-test.png" resize="x1100" declaredimensions=true alt="DoCommand test panel showing detection result with label PASS and confidence score." class="imgzoom shadow">}}
-
-The module is now ready. You'll configure automatic detection in the next section.
-
-## 4.4 Configure Detection Data Capture
-
-In Part 2, you captured images from the vision service. Those images are great for visual review, but they're binary data—you can't query them with SQL. Now you'll configure **tabular data capture** on your inspector's DoCommand, which will let you query detection results.
-
-**Add inspector-service as a data manager dependency:**
-
-The data manager needs to know about your inspector service before it can capture data from it. You'll add this dependency in the JSON configuration.
-
-1. In the **Configure** tab, click **JSON** in the upper left
-2. Find the `data-service` entry in the `services` array
-3. Add `"depends_on": ["inspector-service"]` to the data-service configuration:
-
-   ```json
-   {
-     "name": "data-service",
-     "api": "rdk:service:data_manager",
-     "model": "rdk:builtin:builtin",
-     "attributes": { ... },
-     "depends_on": ["inspector-service"]
-   }
-   ```
-
-4. Click **Save**
-
-This tells viam-server to wait for `inspector-service` to initialize before the data manager tries to capture data from it.
-
-**Enable data capture on the inspector:**
-
-1. In the **Configure** tab, click on `inspector-service` to open its configuration panel
-2. Find the **Data capture** section and click **Add method**
-3. Select the method: `DoCommand`
-4. Set **Frequency (hz)** to `0.5` (captures every 2 seconds)
-5. In the **Additional parameters** section, add the DoCommand input:
-
-   ```json
-   {
-     "detect": true
-   }
-   ```
-
-6. **Save** your configuration
-
-This configuration tells the data manager to periodically call `DoCommand({"detect": true})` on your inspector and capture the response—which includes `label` and `confidence`.
-
-**Query detection results:**
-
-After a few minutes of data collection, you can query the results:
-
-1. Open the **Data** tab in the Viam app
-2. Click **Query**
-3. Select **SQL** as your query language
-
-   {{<imgproc src="/tutorials/first-project/data-query-sql.png" resize="x1100" declaredimensions=true alt="Data Query interface with SQL selected." class="imgzoom shadow">}}
-
-4. Run a query to see recent detections:
-
-   ```sql
-   SELECT time_received, component_name, data
-   FROM readings
-   ORDER BY time_received DESC
-   LIMIT 10
-   ```
-
-   You can also filter to show only failures:
-
-   ```sql
-   SELECT time_received,
-          data.docommand_output.label,
-          data.docommand_output.confidence
-   FROM readings
-   WHERE data.docommand_output.label = 'FAIL'
-   ORDER BY time_received DESC
-   LIMIT 10
-   ```
-
-**Understanding the data structure:**
-
-Each captured detection is stored as a JSON document. Here's what the data looks like:
-
-```json
-{
-  "component_name": "inspector-service",
-  "component_type": "rdk:service:generic",
-  "method_name": "DoCommand",
-  "time_received": "2026-02-02T02:23:27.326Z",
-  "data": {
-    "docommand_output": {
-      "label": "PASS",
-      "confidence": 0.9999136328697205
-    }
-  },
-  "additional_parameters": {
-    "docommand_input": {
-      "detect": true
-    }
-  },
-  "organization_id": "...",
-  "location_id": "...",
-  "robot_id": "...",
-  "part_id": "..."
-}
-```
-
-The key fields for analysis are nested under `data.docommand_output`:
-
-- `label`: The detection result—`PASS`, `FAIL`, or `NO_DETECTION`
-- `confidence`: How confident the model is (0.0 to 1.0)
-
-**Querying with MQL:**
-
-You can also query using MQL (MongoDB Query Language), which is useful for aggregations. Select **MQL** in the Query interface. For example, to count failures by hour:
-
-```javascript
-[
-  {
-    $match: {
-      component_name: "inspector-service",
-      "data.docommand_output.label": "FAIL",
-    },
-  },
-  {
-    $group: {
-      _id: { $dateTrunc: { date: "$time_received", unit: "hour" } },
-      count: { $sum: 1 },
-    },
-  },
-  { $sort: { _id: -1 } },
-];
-```
-
-You'll use MQL aggregation pipelines in Part 5 to build dashboard widgets.
-
-{{< alert title="Two types of captured data" color="info" >}}
-You now have two complementary data streams:
-
-- **Vision service images** (Part 2): Visual records for review and model retraining
-- **Inspector tabular data** (this section): Queryable detection results for analytics
-
-The images show what the system saw; the tabular data tracks what it decided.
-{{< /alert >}}
-
-## 4.5 Summary
-
-You deployed your inspection logic as a Viam module:
-
-1. **Reviewed**—the generator already created module structure and registration
-2. **Deployed**—built, packaged, uploaded, configured
-3. **Configured data capture**—detection results are now queryable
-
-**The development pattern:**
-
-- During development: CLI runs locally, uses remote hardware (fast iteration)
-- In production: Module runs on machine, same code (autonomous operation)
-
-**Your inspection system now runs 24/7** detecting defects without your laptop connected.
-
-**[Continue to Part 5: Productize →](../part-5/)**
diff --git a/docs/operate/hello-world/first-project/part-5.md b/docs/operate/hello-world/first-project/part-5.md
deleted file mode 100644
index 47614b95bd..0000000000
--- a/docs/operate/hello-world/first-project/part-5.md
+++ /dev/null
@@ -1,266 +0,0 @@
----
-linkTitle: "Part 5: Productize"
-title: "Part 5: Productize"
-weight: 50
-layout: "docs"
-type: "docs"
-description: "Build a monitoring dashboard for your inspection system using Viam's Teleop interface."
-date: "2025-01-30"
-aliases:
-  - /operate/hello-world/first-project/part-6/
----
-
-**Goal:** Build a dashboard to monitor your inspection system.
-
-**Skills:** Creating Teleop workspaces, configuring dashboard widgets, writing MQL aggregation pipelines.
-
-**Time:** ~10 min
-
-## What You'll Build
-
-You've built a working inspection system—but monitoring it requires navigating through the Viam app's configuration and data tabs. In this section, you'll create a dedicated dashboard that shows everything at a glance: live camera feeds and defect trends over time.
-
-Viam's Teleop interface lets you create custom monitoring dashboards. You'll add widgets for camera streams and time series graphs that use MQL aggregation pipelines to analyze your detection data.
-
-## 5.1 Create a Workspace
-
-A workspace is a custom dashboard view for your machines.
-
-1. In the Viam app, go to **Fleet** → **Teleop**
-2. Click **+ Create workspace**
-3. Replace the placeholder name with `inspection`
-4. In **Select location**, choose `Home` (or your location name)
-5. In **Select machine**, choose `inspection-station-1`
-
-{{<imgproc src="/tutorials/first-project/teleop-workspaces.png" resize="x1100" declaredimensions=true alt="Teleop workspaces page showing the Create workspace button." class="imgzoom shadow">}}
-
-You now have an empty workspace ready for widgets.
-
-## 5.2 Add a Camera Stream Widget
-
-Add a live video feed from your inspection camera.
-
-1. Click **+ Add widget**
-2. Select **Camera Stream**
-3. Click the pencil icon to configure
-4. Set **Camera name** to `inspection-cam`
-5. Set **Refresh type** to `Live`
-6. Click **Save**
-
-You should see the live feed from your inspection camera with cans passing on the conveyor belt.
-
-## 5.3 Add a Defects Per Minute Widget
-
-Now you'll create a time series graph showing how many defective cans are detected per minute. This requires a custom MQL aggregation pipeline to filter for failures and count them in time buckets.
-
-**Recall the data structure** from Part 4—each detection looks like:
-
-```json
-{
-  "component_name": "inspector-service",
-  "time_received": "2026-02-02T02:23:27.326Z",
-  "data": {
-    "docommand_output": {
-      "label": "FAIL",
-      "confidence": 0.965815
-    }
-  }
-}
-```
-
-You'll write MQL stages that filter for `FAIL` labels and count them per minute.
-
-**Create the widget:**
-
-1. Click **+ Add widget**
-2. Select **Time Series**
-3. Click the pencil icon to configure
-4. Set **Title** to `Defective cans per minute`
-5. Set **Time range (min)** to `60`
-6. Set **Refetch rate (sec)** to `60`
-7. Leave **Y axis lower bound** and **Y axis upper bound** as `auto`
-
-**Configure the line:**
-
-8. Set **Resource name** to `inspector-service`
-9. Set **Capture method** to `DoCommand`
-10. Set **Title** to `Defects`
-11. For **Window method**, select **Custom query**
-
-**Add the MQL stages:**
-
-The custom query method lets you write MongoDB aggregation pipeline stages. You need three stages: match, group, and project.
-
-12. In **Custom MQL Stages**, add a `$match` stage to filter for failures only:
-
-    ```json
-    {
-      "$match": {
-        "data.docommand_output.label": "FAIL"
-      }
-    }
-    ```
-
-13. Click **+ Add stage** and add a `$group` stage to count failures per 60-second bucket:
-
-    ```json
-    {
-      "$group": {
-        "_id": {
-          "$dateTrunc": {
-            "date": "$time_received",
-            "unit": "second",
-            "binSize": 60
-          }
-        },
-        "value": {
-          "$sum": 1
-        }
-      }
-    }
-    ```
-
-14. Click **+ Add stage** and add a `$project` stage to format the output:
-
-    ```json
-    {
-      "$project": {
-        "time": "$_id",
-        "value": true
-      }
-    }
-    ```
-
-15. Click **Save**
-
-The graph now shows the count of defective cans detected in each minute.
-
-{{< alert title="How the pipeline works" color="info" >}}
-
-- **$match** filters to only FAIL detections
-- **$group** buckets data into 60-second intervals and counts documents in each bucket
-- **$project** renames `_id` to `time` (required format for the graph)
-
-<!-- prettier-ignore -->
-{{< /alert >}}
-
-## 5.4 Add a Confidence Trend Widget
-
-Add another time series showing the average confidence of failure detections over time. This helps you monitor model performance—if confidence drops, you may need to retrain.
-
-1. Click **+ Add widget**
-2. Select **Time Series**
-3. Click the pencil icon to configure
-4. Set **Title** to `Confidence`
-5. Set **Time range (min)** to `60`
-6. Set **Refetch rate (sec)** to `60`
-7. Set **Y axis lower bound** to `0`
-8. Set **Y axis upper bound** to `1`
-
-**Configure the line:**
-
-9. Set **Resource name** to `inspector-service`
-10. Set **Capture method** to `DoCommand`
-11. Set **Title** to `FAIL confidence`
-12. For **Window method**, select **Custom query**
-
-**Add the MQL stages:**
-
-13. Add a `$match` stage:
-
-    ```json
-    {
-      "$match": {
-        "data.docommand_output.label": "FAIL"
-      }
-    }
-    ```
-
-14. Click **+ Add stage** and add a `$group` stage that averages confidence:
-
-    ```json
-    {
-      "$group": {
-        "_id": {
-          "$dateTrunc": {
-            "date": "$time_received",
-            "unit": "second",
-            "binSize": 60
-          }
-        },
-        "value": {
-          "$avg": {
-            "$convert": {
-              "input": "$data.docommand_output.confidence",
-              "to": "double",
-              "onError": "$data.docommand_output.confidence"
-            }
-          }
-        }
-      }
-    }
-    ```
-
-15. Click **+ Add stage** and add a `$project` stage:
-
-    ```json
-    {
-      "$project": {
-        "time": "$_id",
-        "value": true
-      }
-    }
-    ```
-
-16. Click **Save**
-
-The graph shows average confidence for failure detections over time.
-
-{{< alert title="Why use $convert?" color="info" >}}
-The `$convert` operator ensures the confidence value is treated as a number for averaging. The `onError` fallback handles any edge cases where conversion fails.
-{{< /alert >}}
-
-## 5.5 Arrange Your Dashboard
-
-Drag widgets to create a useful layout:
-
-1. Click and drag the grid icon in the top-left corner of each widget
-2. Position the camera stream on the right for real-time monitoring
-3. Stack the time series graphs on the left to compare defect counts and confidence trends
-
-Your dashboard now provides a complete view of your inspection system:
-
-- **Live video** showing the inspection in progress
-- **Defects per minute** tracking production quality
-- **Confidence trend** monitoring model performance
-
-{{<imgproc src="/tutorials/first-project/finished-dashboard.png" resize="x1100" declaredimensions=true alt="Finished dashboard showing Defective cans per minute graph, Confidence graph, and live camera stream." class="imgzoom shadow">}}
-
-## 5.6 Summary
-
-You've created a monitoring dashboard using MQL aggregation pipelines:
-
-1. **Created a workspace** for your inspection station
-2. **Added a camera stream** for live video monitoring
-3. **Built a defects graph** using $match → $group (count) → $project
-4. **Built a confidence graph** using $match → $group (average) → $project
-
-The same MQL pipeline pattern—filter, aggregate, project—can be adapted for other metrics: pass rate, throughput, detection latency, or any data your system captures.
-
-{{< alert title="Going further" color="tip" >}}
-For fully custom dashboards with your own branding, you can build web applications using Viam's TypeScript SDK. The SDK provides access to the same data through `tabularDataByMQL()` and `tabularDataBySQL()` methods.
-{{< /alert >}}
-
-## Congratulations
-
-You've completed the tutorial. Here's what you built:
-
-1. **Vision Pipeline**—Camera, ML model, and vision service detecting defects
-2. **Data Capture**—Automatic recording and cloud sync of images and detections
-3. **Control Logic**—Custom inspector module exposing detection through DoCommand
-4. **Module Deployment**—Packaged and deployed to run autonomously
-5. **Productize**—Monitoring dashboard with real-time analytics
-
-You've gone from an empty machine to a production-ready inspection system with monitoring—patterns that apply to any Viam application.
-
-**[← Back to Overview](../)** to review what you learned.
diff --git a/docs/operate/hello-world/first-project/sim-setup.md b/docs/operate/hello-world/first-project/sim-setup.md
deleted file mode 100644
index 2a11fcd0e6..0000000000
--- a/docs/operate/hello-world/first-project/sim-setup.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-linkTitle: "Simulation Setup"
-title: "Simulation Setup"
-weight: 100
-layout: "docs"
-type: "docs"
-description: "Set up the hosted simulation environment for the inspection tutorial."
-date: "2025-01-30"
-aliases:
-  - gazebo-setup
----
-
-This guide walks you through setting up the Gazebo simulation used in the [Your First Project](../) tutorial.
-
-## Step 1: Start a Simulation Environment
-
-Visit [cans.viam-labs.com](https://cans.viam-labs.com), and follow the prompts to log in. Wait for your instance to start.
-
-{{< alert title="Note" color="note" >}}
-The simulation session has a 1 hour time limit, but can be extended. Watch the session time in the top toolbar.
-{{< /alert >}}
-
-## Step 2: Verify the Simulation
-
-When your instance is finished starting, you should see two live camera feeds from the inspection station:
-
-{{<imgproc src="/tutorials/first-project/sim-viewer.png" resize="x1100" declaredimensions=true alt="Simulation web viewer showing the Can Inspection Station with Overview Camera and Inspection Camera feeds." class="imgzoom shadow">}}
-
-If the camera feeds every go dark or stops responding, try refreshing the page or press <kbd>Ctrl</kbd>+<kbd>R</kbd>.
-
-## Step 3: Create a Machine in Viam
-
-1. Go to [app.viam.com](https://app.viam.com) and create a free account or log in
-2. Click the **Locations** tab
-3. Click **+ Add machine**, name it `inspection-station-1`, and click **Add machine**
-
-   {{<imgproc src="/tutorials/first-project/fleet-add-machine.png" resize="x1100" declaredimensions=true alt="Viam app Fleet page showing First Location with no machines and the Add machine button." class="imgzoom shadow">}}
-
-## Step 4: Configure Machine Credentials
-
-1. In the Viam app, click the **Awaiting setup** button on your new machine and click **Machine cloud credentials** to copy the credentials JSON
-
-   {{<imgproc src="/tutorials/first-project/awaiting-setup.png" resize="x1100" declaredimensions=true alt="Viam app showing the Awaiting setup dropdown with Machine cloud credentials option." class="imgzoom shadow">}}
-
-2. In the simulation viewer, click the **Configuration** button in the upper right corner
-
-   {{<imgproc src="/tutorials/first-project/sim-viewer-config-button.png" resize="x1100" declaredimensions=true alt="Simulation viewer showing the Configuration button in the upper right corner." class="imgzoom shadow">}}
-
-3. Paste your machine's credentials into the **Viam Configuration (viam.json)** text area and click **Update and Restart**
-
-   {{<imgproc src="/tutorials/first-project/sim-config-page.png" resize="x1100" declaredimensions=true alt="Simulation configuration page with machine cloud credentials pasted into the text area. Viam Server Status shows Stopped." class="imgzoom shadow">}}
-
-   A green banner will confirm the configuration was updated successfully and the status indicator will change to **Running**.
-
-   {{<imgproc src="/tutorials/first-project/sim-config-running.png" resize="x1100" declaredimensions=true alt="Simulation configuration page after restart, showing a green 'Configuration updated successfully' banner and Viam Server Status: Running." class="imgzoom shadow">}}
-
-## Step 5: Verify Machine Connection
-
-Go back to your machine's page in the Viam app.
-The status indicator should now show **Live**.
-
-{{<imgproc src="/tutorials/first-project/viam-app-live.png" resize="x1100" declaredimensions=true alt="Viam app showing inspection-station-1 with a green Live status indicator." class="imgzoom shadow">}}
-
-## Ready to Continue
-
-Once your machine shows **Live** in the Viam app, you're ready to continue with the tutorial.
-
-**[Continue to Part 1: Vision Pipeline →](../part-1/)**
diff --git a/docs/operate/hello-world/problems-viam-solves.md b/docs/operate/hello-world/problems-viam-solves.md
deleted file mode 100644
index 7ac99d2104..0000000000
--- a/docs/operate/hello-world/problems-viam-solves.md
+++ /dev/null
@@ -1,150 +0,0 @@
----
-linkTitle: "Problems Viam Solves"
-title: "Problems Viam Solves"
-weight: 15
-layout: "docs"
-type: "docs"
-description: "A guide to the challenges you'll face at each stage of robotics development and how Viam helps."
-date: "2025-01-30"
----
-
-Building a robotics application is hard. This document maps the problems you'll face at each stage and shows where Viam helps.
-
-## Stage 1: Prototype
-
-_You're building something that works on your bench._
-
-### The Problems
-
-**Hardware integration is painful.** Every sensor and actuator has its own SDK, its own quirks, and its own incompatibilities. You spend more time debugging drivers than building features.
-
-**Communication protocols are arcane.** I2C, SPI, UART, and CAN each have their own timing, addressing, and failure modes. Working with different protocols slows the pace of development.
-
-**Development is tied to the device.** You're SSH'ing in, editing files, and restarting processes. The iteration loop is slow and frustrating.
-
-**There's no consistency.** Code for one camera doesn't work with another. Switching motors means rewriting control logic. Everything is bespoke.
-
-**Building intelligence is even harder.** Object detection requires ML pipelines. Motion planning requires complex algorithms. Building these from scratch distracts from your actual application.
-
-### How Viam Helps
-
-**Viam's Registry** provides pre-built, tested modules for 200+ components. You configure your hardware in a simple JSON file rather than writing driver code.
-
-**Communication protocols are entirely abstracted**. You never have to think about I2C versus SPI. Viam abstracts away the different protocols, giving you a consistent API across cameras, sensors, motors, etc.
-
-**Develop code anywhere.** Write code on your laptop in your IDE. Run it against your robot over the network.
-
-**SDKs and APIs work across all hardware.** To swap one camera for another in Viam, you change a few lines of a configuration file. Your code stays the same.
-
-**Built-in services for vision and motion.** Object detection, classification, and segmentation work out of the box. Motion planning handles path optimization and collision avoidance. Focus on what your robot should do, not how to make it see and move.
-
-## Stage 2: First Deployment
-
-_Your robot leaves the bench and enters the real world._
-
-### The Problems
-
-**The environment is hostile.** Lighting changes, dust accumulates, and temperatures vary. Solutions that worked on your bench fail in the field.
-
-**Calibration is tedious.** Camera-arm setups need precise spatial relationships for motion planning. This type of calibration is difficult and time-consuming.
-
-**Network access is complicated.** Your robot is behind a firewall. NAT makes inbound connections impossible. You can't just SSH in.
-
-**You can't see what's happening.** When something goes wrong, you're blind. Logs are on the device. Sensor feeds are inaccessible. Debugging remotely is not possible.
-
-**Available models don't fit your use case.** Pre-trained models rarely recognize your specific objects or scenarios. Training custom models requires infrastructure that is a project in itself.
-
-### How Viam Helps
-
-**Diagnose environmental issues remotely.** When lighting, temperature, or dust cause unexpected behavior, view live camera feeds and sensor data to identify problems. Adjust configuration from the cloud.
-
-**Remote access works through firewalls.** WebRTC handles NAT traversal automatically. You do not need to set up a VPN or port forwarding.
-
-**Pre-computed transforms** are available for common hardware combinations. Reusable configuration blocks (fragments) include the spatial relationships your motion planner needs. No manual calibration is required for supported camera-arm setups.
-
-**You can see everything remotely.** Live sensor feeds, component status, and logs are all accessible from the Viam app or your code, which can run from anywhere.
-
-**Configuration pushes from the cloud.** When you need to adjust settings in the field, you don't need to touch the device.
-
-**Train custom models on captured data.** Capture images from your deployed robots, annotate them, and train models within Viam's data management infrastructure.
-
-## Stage 3: Multiple Units
-
-_You've proven the concept. Now you're deploying 5, 10, 50 robots._
-
-### The Problems
-
-**Setup doesn't scale.** Manually configuring each device takes hours. Mistakes creep in. Units drift out of sync.
-
-**Hardware is never identical.** Different sensor batches and revisions create subtle variations.
-
-**Updates are error-prone.** You either need to write your own fleet deployment infrastructure or deploy updates to each machine, one at a time.
-
-### How Viam Helps
-
-**Provisioning is streamlined.** New devices connect to the cloud and pull their configuration automatically.
-
-**Fragments are reusable configurations.** Define a camera-arm combination, a vision pipeline, or an entire work cell once. Apply it to any number of machines. Override per-machine differences (different camera model, site-specific settings) without forking the base fragment.
-
-**Staged rollouts** let you push updates to one device, then ten, then all, with rollback if something goes wrong.
-
-## Stage 4: Fleet at Scale
-
-_You're operating hundreds or thousands of robots—and delivering to customers._
-
-### The Problems
-
-**Visibility is overwhelming.** Monitoring every device individually is not feasible. You need systems that surface which devices require attention.
-
-**Updates are high-stakes.** A bad update can disrupt production across your fleet. You need mechanisms to stage and validate changes.
-
-**Customers expect dashboards.** They want to see their robots. You need to provide access without building auth systems, billing infrastructure, and dashboards from scratch.
-
-### How Viam Helps
-
-**Fleet monitoring** shows health across all devices at a glance. Anomalies surface automatically.
-
-Viam enables **OTA updates at scale** with staged rollouts, canary deployments, and rollback.
-
-**Customer delivery infrastructure built in.** White-label authentication with your branding. TypeScript SDK for web dashboards, Flutter SDK for mobile apps. Built-in billing with per-machine or per-data pricing tiers.
-
-## Stage 5: Ongoing Maintenance
-
-_The fleet is running. Now you maintain it forever._
-
-### The Problems
-
-**Remote debugging is essential.** Without physical access to devices, you need visibility into logs, sensor state, and system health.
-
-**Logs are scattered.** Retrieving logs from devices with intermittent connectivity requires dedicated infrastructure.
-
-**Maintenance tasks pile up.** Periodic calibrations, health checks, and sensor readings require scheduling infrastructure such as cron jobs or custom schedulers.
-
-**Models drift.** The ML model that worked at launch degrades over time. You need to retrain and redeploy.
-
-### How Viam Helps
-
-**Remote log access** includes offline buffering. Logs synchronize automatically when connectivity is restored.
-
-**Scheduled tasks without custom schedulers.** Viam runs periodic sensor readings, daily calibrations, and health checks at specified intervals without requiring cron jobs or external scheduling infrastructure.
-
-**Data pipelines** capture real-world performance continuously. Use this data to identify issues and retrain models.
-
-**One-click model deployment** allows you to update ML models across the fleet.
-
-## Summary
-
-| Stage     | Pain                                              | Viam Solution                                                                     |
-| --------- | ------------------------------------------------- | --------------------------------------------------------------------------------- |
-| Prototype | Hardware integration, slow iteration              | Viam Registry, develop from anywhere, consistent APIs, built-in vision and motion |
-| Deploy    | Calibration, remote access, visibility, model fit | Pre-computed transforms, WebRTC, remote diagnostics, model training               |
-| Scale     | Configuration management                          | Reusable configuration blocks (fragments), staged rollouts                        |
-| Fleet     | Visibility, updates, customer delivery            | Monitoring, OTA, white-label auth, billing                                        |
-| Maintain  | Remote debugging, scheduled tasks, model drift    | Log access, scheduled jobs, model deployment                                      |
-
-## Next steps
-
-{{< cards >}}
-{{% card link="/operate/hello-world/what-is-viam/" %}}
-{{% card link="/operate/hello-world/tutorial-desk-safari/" %}}
-{{< /cards >}}
diff --git a/docs/operate/hello-world/tutorial-desk-safari.md b/docs/operate/hello-world/tutorial-desk-safari.md
deleted file mode 100644
index bfce0af041..0000000000
--- a/docs/operate/hello-world/tutorial-desk-safari.md
+++ /dev/null
@@ -1,792 +0,0 @@
----
-linkTitle: "Tutorial: Desk Safari"
-title: "Tutorial: Desk Safari"
-weight: 20
-layout: "docs"
-type: "docs"
-videos: ["/build/game-preview.webm", "/build/game-preview.mp4"]
-videoAlt: "Desk Safari game preview"
-images: ["/build/game-preview.gif"]
-imageAlt: "Desk Safari game preview"
-level: "Beginner"
-languages: ["python"]
-viamresources: ["camera", "vision", "button"]
-cost: "0"
-date: "2025-09-24"
-no_list: false
-description: "Follow this tutorial to learn about Viam while building a game."
-authors: ["Naomi Pentrel"]
----
-
-In this tutorial you will build a game with your webcam while learning how to use Viam to build any machine that interacts with the physical world:
-
-- [Device setup](#device-setup) will walk you through installing Viam on your computer.
-- [Use a webcam](#use-a-webcam) will guide you through configuring and testing camera resources in Viam.
-- [Add computer vision](#add-computer-vision) will show you how to integrate higher-level services such as ML model and vision services.
-- [Program your game](#program-your-game) will teach you to build custom modules and implement the game control logic.
-- [Play the game](#play-the-game) will let you test and interact with your completed game.
-
-You don't need any prior knowledge of Viam.
-
-## Game overview
-
-The Desk Safari game you will build works as follows:
-
-1. **Game Start**: The player presses a button to begin
-2. **Round Duration**: Each round lasts up to 60 seconds
-3. **Item Detection**: The player must show a prompted item to the camera
-4. **Scoring**: If the item is detected with ≥50% confidence, the player scores a point and gets a new item
-5. **Game End**: If no item is detected within 60 seconds, the round ends
-6. **Restart**: The player can press the button again to start a new game
-
-{{<video webm_src="/build/game.webm" mp4_src="/build/game.mp4" poster="/build/game.jpg" alt="A game of Desk Safari where the player holds up different items to the camera to score points">}}
-
-## Prerequisites
-
-- A laptop or desktop computer with a webcam (USB, built-in, or wireless)
-- Python 3.8+ installed on your computer
-- Basic familiarity with Python programming
-- Basic familiarity with command line/terminal usage
-
-## Device setup
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Create a Viam account and log in.**
-
-Navigate to [Viam](https://app.viam.com) in a web browser.
-Create a free account and log in.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Navigate to your first location.**
-
-Click **FLEET** in the upper-left corner of the page and click **LOCATIONS**.
-Then select the `First Location`.
-
-Viam automatically created an {{< glossary_tooltip term_id="organization" text="organization" >}} for you and a {{< glossary_tooltip term_id="location" text="location" >}} called `First Location`.
-You can create more organizations and locations to organize your machines, but for this tutorial you can use the automatically created ones.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Create a new machine.**
-
-Click **+ Add machine** to create your first machine and name it `hello-world`.
-
-A {{< glossary_tooltip term_id="machine" text="machine" >}} represents at least one computer running `viam-server` along with all the hardware components and software services that the computer controls.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Install `viam-server`.**
-
-On the machine's page, follow the {{< glossary_tooltip term_id="setup" text="setup instructions" >}} to install `viam-server` on the computer you're using for your project.
-If you can choose an installation method, use `viam-agent`.
-
-Wait until your machine has successfully connected to Viam.
-
-{{<imgproc src="/tutorials/hello-world/connected.png" resize="800x" style="width: 500px" declaredimensions=true alt="A machine showing a successful connection." class="imgzoom shadow">}}
-
-{{% /tablestep %}}
-{{< /table >}}
-
-By installing `viam-server` on your device, you've turned your computer into a Viam {{< glossary_tooltip term_id="machine" text="machine" >}}.
-
-At this point, your machine only runs the Viam software.
-To make your machine do something interesting, you must add functionality to it.
-
-When you use Viam to build a machine, you mix and match different building blocks to make the machine do exactly what you need.
-The building blocks you'll use in this tutorial are **components**, **services**, and **modules**.
-These are the main building blocks that make up all machines.
-
-Let's start by adding a component.
-
-## Use a webcam
-
-{{< glossary_tooltip term_id="component" text="Components" >}} are the resources that your machine uses to sense and interact with the world, such as cameras, motors, sensors, and more.
-
-For this tutorial, you can use any webcam that is connected to your computer: a USB webcam, a built-in one, or a wireless one.
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Navigate to the CONFIGURE tab of your machine's page.**
-
-This page is where you configure all hardware and software for a machine.
-There are different kinds of {{< glossary_tooltip term_id="resource" text="resources" >}} you can use.
-
-{{% /tablestep %}}
-
-{{% tablestep %}}
-**Configure the webcam to use for the Desk Safari game.**
-
-Click the **+** icon next to your machine part in the left-hand menu and select **Configuration block**.
-Select the `camera` type, then select the `webcam` model.
-Use the default name `camera-1` for your camera and click **Create**.
-
-You can leave the `video_path` empty.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Save your config.**
-
-Always save your config before testing.
-This will apply your changes to your machine.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Test the camera stream.**
-
-Click on the camera's **TEST** panel to see the camera stream.
-
-The **TEST** panel is a good tool to ensure {{< glossary_tooltip term_id="resource" text="resources" >}} are working as expected.
-
-{{< imgproc src="/components/camera/example_camera_2.png" alt="Example Camera view" resize="800x" style="width:500px" class="imgzoom shadow" >}}
-
-If your camera is not working, follow the info in the camera panel to add the webcam discovery service.
-Once you save, use the discovery service's test panel to find camera configurations and add a new camera
-Make sure to name the camera `camera-1`.
-If this doesn't work, see [Troubleshooting](/operate/reference/components/camera/webcam/#troubleshooting) and [Common errors](/operate/reference/components/camera/webcam/#common-errors).
-
-{{% /tablestep %}}
-{{< /table >}}
-
-You can now see your camera stream on Viam.
-Next, you’ll apply computer vision to this stream.
-
-## Add computer vision
-
-{{< glossary_tooltip term_id="service" text="Services" >}} are higher-level software capabilities that process and interpret data or interact with the world.
-Viam provides many different services, including ones to run machine learning models and computer vision.
-
-For this tutorial, you will use:
-
-- a model called `EfficientDet-COCO`, which is publicly available. The model can detect a variety of objects. You can see all objects in the <file>[labels.txt](/tutorials/labels.txt)</file> file.
-- an ML model service, which runs a machine learning model on your machine and returns inferences.
-- a vision service, which uses the machine learning model, applies it to the camera stream, and returns any objects it identifies.
-
-Let's configure all these:
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Add multiple resources in one step.**
-
-On the **CONFIGURE** tab, click **+** and select **Configuration block**.
-Search for `HelloWorldMLResources` by the `Robot Land` organization and select it.
-Click **Add fragment**, then click **Add fragment** again to confirm.
-This adds a vision service named `object-detector` and a model for it.
-Save your config.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Investigate the new resources.**
-
-A {{< glossary_tooltip term_id="fragment" text="fragment" >}} constitutes a set of {{< glossary_tooltip term_id="resource" text="resources" >}} which are often used together.
-In this case, the fragment contains the module that contains the ML model service which runs the model, as well as a vision service that applies the model to the camera stream.
-
-Review the config for each new resource and click on their **TEST** panels to try them.
-
-{{% /tablestep %}}
-{{< /table >}}
-
-If you check the resources added by the fragment, you'll see an additional resource called `tflite_cpu`.
-This is a {{< glossary_tooltip term_id="module" text="module" >}}.
-Modules are packages of code that contain components and services.
-They're like plugins that expand what your machine can do without modifying Viam's core software.
-
-Viam has a registry of modules that contain resources you can use when building your machines.
-Of course, you can also build your own modules and resources.
-In fact, you will create a resource for the game's control logic in the next step.
-
-## Program your game
-
-The game loop works as follows:
-
-- The player presses a button to start the game.
-- The game provides the player with a prompt showing an item to find and hold up to the camera within 60 seconds.
-- If the vision service detects a matching object within 60 seconds, the player scores a point and a new round begins with a new item.
-- If no matching object is detected within 60 seconds, the current round ends and the game stops.
-- The player can press the button again to start a new game with a fresh score.
-
-Now that you have the camera and vision service working, you need to create the game logic that ties them together.
-This logic will implement the game mechanics.
-
-To implement the logic, you'll create your own {{< glossary_tooltip term_id="resource" text="resource" >}} and package it inside a {{< glossary_tooltip term_id="module" text="module" >}}.
-
-Viam provides a range of standardized component and service APIs.
-When you create a resource, you implement the API among them that most closely fits your needs.
-
-The Button API fits perfectly for the game as it provides the methods `Push` and `DoCommand`.
-
-The `Push` method works great for starting the game. If you think about it, when a player starts the game, they're essentially pushing a button to issue the start command.
-
-`DoCommand` is often used to implement control logic, as you can pass commands as arbitrary JSON objects, such as `{"action": "run_game_loop"}`.
-You can use the `DoCommand` method to implement everything that doesn't fit into other API methods.
-
-In the next steps, you'll create your own module which implements the game logic using the Button API.
-
-To create your game logic module, you'll use the Viam CLI to generate code that already includes the Button API template.
-This saves you from writing boilerplate code.
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Install the CLI.**
-
-You must have the Viam CLI installed to generate and upload modules:
-
-{{< readfile "/static/include/how-to/install-cli.md" >}}
-{{% /tablestep %}}
-{{% tablestep %}}
-**Log in with the CLI.**
-
-Run the following command to log in:
-
-```sh {class="command-line" data-prompt="$" data-output="2-10"}
-viam login
-```
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Find your organization ID.**
-
-Run the following command to list your organizations and their IDs:
-
-```sh {class="command-line" data-prompt="$" data-output="2-10"}
-viam organization list
-Organizations for "user@viam.com":
-    User's org (id: a12b3c4d-1234-123a-12a3-a1b23c45d67e)
-```
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Generate the module template.**
-
-Replace `<ORGANIZATION-ID>` with your organization ID, which resembles: `a12b3c4d-1234-123a-12a3-a1b23c45d67e`.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```sh {class="command-line" data-prompt="$" data-output="4-10"}
-viam module generate --language python --model-name game-logic \
-  --name hello-world-game-py --public-namespace <ORGANIZATION-ID> \
-  --resource-subtype=button
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Inspect the generated files.**
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-The module generator creates the following files:
-
-```treeview
-hello-world-game-py/
-└── src/
-|   ├── models/
-|   |   └── game_logic.py
-|   └── main.py
-└── README.md
-└── <org-id>_game-logic_hello-world-game-py.md
-└── build.sh
-└── meta.json
-└── requirements.txt
-└── run.sh
-└── setup.sh
-```
-
-The CLI generated several files, but you'll only need to modify <FILE>game_logic.py</FILE> to implement your game.
-If you want to understand the module structure, here's what each file does:
-
-- **<FILE>README.md</FILE>**: Documentation template that gets uploaded to the registry when you upload the module.
-- **<FILE>namespace_module_model.md</FILE>**: Documentation template for the model that gets uploaded to the registry when you upload the module.
-- **<FILE>meta.json</FILE>**: Module metadata that gets uploaded to the registry when you upload the module.
-- **<FILE>main.py</FILE>** and **<FILE>game_logic.py</FILE>**: Core code that registers the module and resource and provides the model implementation.
-- **<FILE>setup.sh</FILE>** and **<FILE>requirements.txt</FILE>**: Setup script that creates a virtual environment and installs the dependencies listed in <FILE>requirements.txt</FILE>.
-- **<FILE>build.sh</FILE>**: Build script that packages the code for upload.
-- **<FILE>run.sh</FILE>**: Script that runs <FILE>setup.sh</FILE> and then executes the module from <FILE>main.py</FILE>.
-
-{{< alert title="Full code" color="tip" >}}
-
-The following steps walk through each step to change the code.
-You can also reference the full code [on GitHub](https://github.com/viam-labs/hello-world-game-module).
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Setup the imports for the game.**
-
-Open <FILE>hello-world-game-py/src/models/game_logic.py</FILE>.
-This is the template for the Button API to which you will add the game logic.
-
-To implement the game mechanics, you'll need these Python packages:
-
-```python {class="line-numbers linkable-line-numbers" }
-import random
-from datetime import datetime, timedelta
-
-from typing import cast
-from viam.services.vision import *
-```
-
-The packages allow you to:
-
-- pick a random item
-- implement the time logic for the game
-- use the vision package
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Add class attributes for the game.**
-
-Class attributes are variables that belong to the class itself rather than to any specific instance of the class.
-They are shared among all instances of the class and are defined at the class level.
-
-For the Desk Safari game, you need to provide the game with a list of items to choose from for the prompt.
-This list should not change between instances, so it can be defined as a class variable.
-You can remove any items you don't have in your home from the list.
-
-```python {class="line-numbers linkable-line-numbers" data-start="20" data-line="8-20" }
-class GameLogic(Button, EasyResource):
-    # To enable debug-level logging, either run viam-server with the --debug
-    # option, or configure your resource/machine to display debug logs.
-    MODEL: ClassVar[Model] = Model(
-        ModelFamily("<namespace>", "hello-world-game-py"), "game-logic"
-    )
-
-    POSSIBLE_OPTIONS: ClassVar[List[str]] = [
-        "Person", "Cat", "Dog", "Hat", "Backpack", "Umbrella", "Shoe",
-        "Eye glasses", "Handbag", "Tie", "Suitcase", "Frisbee", "Sportsball",
-        "Plate", "Cup", "Fork", "Knife", "Spoon", "Bowl", "Banana", "Apple",
-        "Sandwich", "Orange", "Broccoli", "Carrot", "Pizza", "Donut", "Cake",
-        "Chair", "Couch", "Potted plant", "Mirror", "Desk", "Door", "Tv",
-        "Laptop", "Mouse", "Keyboard", "Cellphone", "Blender", "Book", "Clock",
-        "Vase", "Scissors", "Teddy bear", "Hair drier", "Toothbrush",
-        "Hair brush"
-    ]
-```
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Validate the button's config.**
-
-Your game needs to know which camera and vision service to use.
-While you could hardcode these names, you'll get them from the button's configuration. This makes your game flexible if you change component names later.
-
-To get parameters from the configuration object, you use the `validate_config` method.
-`viam-server` calls the `validate_config` method before calling `reconfigure` to:
-
-1. Ensure the expected fields are in the config and have the right type.
-   This method makes sure the camera name and vision service name are present and raises errors if they are not provided.
-2. Find out if the resource has required dependencies (`req_deps`).
-   The `validate_config` method returns a list of required dependencies and a list of optional dependencies.
-   If the resource requires other components or services to function, as in this case the camera and the vision service, you must return them as the first array from the method.
-
-   `viam-server` waits until those dependencies are available before starting the button component.
-
-```python {class="line-numbers linkable-line-numbers" data-start="55" }
-    @classmethod
-    def validate_config(
-        cls, config: ComponentConfig
-    ) -> Tuple[Sequence[str], Sequence[str]]:
-        req_deps = []
-        fields = config.attributes.fields
-        if "camera_name" not in fields:
-            raise Exception("missing required camera_name attribute")
-        elif not fields["camera_name"].HasField("string_value"):
-            raise Exception("camera_name must be a string")
-        camera_name = fields["camera_name"].string_value
-        if not camera_name:
-            raise ValueError("camera_name cannot be empty")
-        req_deps.append(camera_name)
-        if "detector_name" not in fields:
-            raise Exception("missing required detector_name attribute")
-        elif not fields["detector_name"].HasField("string_value"):
-            raise Exception("detector_name must be a string")
-        detector_name = fields["detector_name"].string_value
-        if not detector_name:
-            raise ValueError("detector_name cannot be empty")
-        req_deps.append(detector_name)
-        return req_deps, []
-```
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Implement the Push method.**
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-In the <FILE>hello-world-game-py/src/models/game_logic.py</FILE> file, find the `push` method to set the `new_game` attribute to `True` when pushed.
-
-```python {class="line-numbers linkable-line-numbers" data-line="8-9" data-start="90" }
-    async def push(
-        self,
-        *,
-        extra: Optional[Mapping[str, Any]] = None,
-        timeout: Optional[float] = None,
-        **kwargs
-    ) -> None:
-        self.logger.info("`push` is called")
-        self.new_game = True
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}{{% tablestep %}}
-**Initialize all variables.**
-
-Unlike class attributes, instance attributes are unique to a single instance of the button running on your machine.
-You use them to initialize instance parameters, like `self.new_game`, in the `reconfigure` method.
-`viam-server` calls the `reconfigure` method whenever the module starts or a configuration change occurs.
-Whenever you change the config of the button, the parameters get set to the values assigned in the reconfigure method.
-
-You must initialize all variables that can and may be accessed before they are assigned elsewhere in the code.
-For the Desk Safari game, you'll initialize the following game state variables:
-
-- `new_game`: the value set to true when a new game should start
-- `score`: the score
-- `time_round_start`: the time the round started, used to determine when 60 seconds are up
-- `item_to_detect`: the current item that needs to be shown to the camera.
-
-On top of game state variables, you also need to initialize the vision service and camera name so they can be used in the rest of the code.
-The dependencies parameter contains all the resources this component can access.
-By using `cast` you tell Python that the vision resource is specifically a VisionClient.
-
-Update the `reconfigure` method to initialize all the variables:
-
-```python {class="line-numbers linkable-line-numbers" data-start="79" }
-    def reconfigure(
-        self, config: ComponentConfig,
-        dependencies: Mapping[ResourceName, ResourceBase]
-    ):
-        # Game state
-        self.new_game: bool = False
-        self.score: int = 0
-        self.time_round_start: Optional[datetime] = None
-        self.item_to_detect: str = ""
-
-        camera_name = config.attributes.fields["camera_name"].string_value
-        detector_name = config.attributes.fields["detector_name"].string_value
-
-        # Get the full resource name for the vision service
-        # (rdk:service:vision/object-detector)
-        vision_resource_name = VisionClient.get_resource_name(detector_name)
-
-        # Check if the vision resource exists in dependencies
-        if vision_resource_name not in dependencies:
-            raise KeyError(f"Vision service '{detector_name}' not found in "
-                           f"dependencies. Available resources: "
-                           f"{list(dependencies.keys())}")
-
-        vision_resource = dependencies[vision_resource_name]
-        self.detector = cast(VisionClient, vision_resource)
-        self.camera_name = camera_name
-
-        return super().reconfigure(config, dependencies)
-```
-
-{{% /tab %}}
-{{% tablestep %}}
-**Implement the game loop with the DoCommand method.**
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-The last change to the code is to implement the game loop.
-Change the implementation of the `do_command` method to run the game loop when receiving the command parameters `{"action": "run_game_loop"}`
-To make it easy to retrieve the game data (for later parts of the tutorial), the following code will return the data for any call to `do_command`:
-
-```python {class="line-numbers linkable-line-numbers" data-line="8-17" data-start="117" }
-    async def do_command(
-        self,
-        command: Mapping[str, ValueTypes],
-        *,
-        timeout: Optional[float] = None,
-        **kwargs
-    ) -> Mapping[str, ValueTypes]:
-        result = {}
-        for name, args in command.items():
-            if name == "action" and args == "run_game_loop":
-                await self._run_game_loop()
-        # return the current game data for all commands
-        result["score"] = self.score
-        result["time_round_start"] = str(self.time_round_start)
-        result["item_to_detect"] = self.item_to_detect
-        self.logger.info(f"Game data: {result}")
-        return result
-```
-
-The `do_command` method calls another method `_run_game_loop` which implements the game logic.
-Add the `_run_game_loop` method and the other helper methods above the `do_command` method:
-
-```python {class="line-numbers linkable-line-numbers" data-start="117" }
-    async def _run_game_loop(self):
-        try:
-            if self.new_game:
-                await self._start_new_game()
-            if self._is_game_active():
-                await self._check_for_detection()
-            else:
-                await self._handle_game_end()
-
-        except Exception as err:
-            self.logger.error(f"Game state processing error: {err}")
-
-    async def _start_new_game(self):
-        """Initialize a new game round."""
-        self.new_game = False
-        self.logger.info("Game is starting.")
-        self.time_round_start = datetime.now()
-        self.logger.info(f"Round started at {self.time_round_start.strftime('%Y-%m-%d %H:%M:%S')}")
-
-        self.score = 0
-        self.item_to_detect = random.choice(self.POSSIBLE_OPTIONS)
-        self.logger.info(f"Item to detect: {self.item_to_detect}")
-
-    def _is_game_active(self) -> bool:
-        if not self.time_round_start:
-            return False
-
-        # Check if the current round is still active (within 60 seconds).
-        return datetime.now() - self.time_round_start <= timedelta(seconds=60)
-
-    async def _check_for_detection(self):
-        self.logger.info("Checking for item detection")
-
-        detections = await self.detector.get_detections_from_camera(self.camera_name)
-
-        if self._is_target_detected(detections):
-            await self._handle_successful_detection()
-        else:
-            self.logger.info(f"Item not detected: {self.item_to_detect}")
-
-    def _is_target_detected(self, detections) -> bool:
-        for detection in detections:
-            if (detection.class_name == self.item_to_detect and
-                detection.confidence > 0.5):
-                return True
-        return False
-
-    async def _handle_successful_detection(self):
-        self.score += 1
-        self.logger.info(f"Item detected: {self.item_to_detect}")
-        self.logger.info(f"Score: {self.score}")
-
-        # start a new round
-        self.time_round_start = datetime.now()
-        self.logger.info(f"Starting new round at {self.time_round_start.strftime('%Y-%m-%d %H:%M:%S')}")
-        self.item_to_detect = random.choice(self.POSSIBLE_OPTIONS)
-        self.logger.info(f"Item to detect: {self.item_to_detect}")
-
-    async def _handle_game_end(self):
-        if self.time_round_start:  # Only log if there was an active game
-            self.logger.info(f"Round over at {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
-            self.logger.info(f"Final Score: {self.score}")
-            self.time_round_start = None
-            self.item_to_detect = ""
-```
-
-{{% /tablestep %}}
-
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Configure your module as a local module.**
-
-The next step is to run the logic on your machine.
-For production purposes you would upload the module to the registry but for now, let's just test your module by running it locally on your machine.
-
-Navigate to your machine's **CONFIGURE** page.
-Make sure your machine is showing as live and connected to Viam.
-
-Click the **+** button, select **Local module**, then select **Local module** again.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-Enter the path to the <file>run.sh</file> file, for example, `/home/naomi/hello-world-game-py/run.sh` on Linux or `/Users/naomi/hello-world-game-py/run.sh` on macOS.
-Click **Create**.
-
-Save your config.
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Configure your button as a local component.**
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-Click **+**, click **Local module**, then click **Local component** and fill in the fields as follows:
-
-- model namespace triplet: `<namespace>:hello-world-game-py:game-logic`, you can see the full triplet in the module's <FILE>meta.json</FILE> file
-- type: `button`
-- name: `button-1`
-
-Configure the camera and vision service names by pasting the following in the configuration field:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "camera_name": "camera-1",
-  "detector_name": "object-detector"
-}
-```
-
-Save the config.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Restart module every time you iterate.**
-
-If you make changes to your module code, you must restart your module for the changes to take effect.
-Click on the **...** menu near the module and select **Restart**.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Test your game logic.**
-
-Navigate to your machine's **CONTROL** tab and find the button's panel.
-
-1. Click the **PUSH** button to start the game.
-   You should see a log message saying "`push` is called" in the **LOGS** tab:
-
-   ```sh {class="command-line" data-prompt="$" data-output="1-10"}
-   10/6/2025, 5:18:23 PM info rdk:component:button/button-1    game_logic.py:110 `push` is called    log_ts 2025-10-06T17:18:23.672Z
-   ```
-
-2. Open the `DoCommand` panel, add `{ "action": "run_game_loop" }` as the input and click **Execute**.
-   This will call the game loop once and retrieve the score, the time the round started, and the current item to detect.
-   You will see a response in the UI of the format:
-
-   ```json
-   {
-     "score": 0,
-     "time_round_start": "2025-09-24 14:07:49.599761",
-     "item_to_detect": "Bowl"
-   }
-   ```
-
-3. Hold up the `item_to_detect` and click the **Execute** button to test the game.
-   Once successfully detected, the score increases and the `item_to_detect` changes.
-
-   {{< alert title="Tip: Don't spend too long testing" color="tip" >}}
-   Sometimes the model struggles to detect certain items.
-   If that is the case, move on to the next step, once you've ensured there are no errors.
-
-   You can test the game more thorougly with a dedicated UI in [Play the game](#play-the-game).
-
-   {{< /alert >}}
-
-4. If you wait 60 seconds, the game ends and the response you get if you then click **Execute** contains the default values for `item_to_detect` and `time_round_start` and the last score:
-
-   ```json
-   {
-     "item_to_detect": "",
-     "score": 1,
-     "time_round_start": "None"
-   }
-   ```
-
-This manual testing lets you verify the game logic works correctly.
-In the final step, you'll make the game logic run continuously.
-
-If you are encountering errors, check the **LOGS** tab for more information.
-
-{{% /tablestep %}}
-{{% tablestep %}}
-**Run game logic loop automatically with a job.**
-
-To run game logic, we'll use a {{< glossary_tooltip term_id="job" text="job" >}} which calls the `DoCommand` method periodically.
-
-Click the **+** icon next to your machine part in the left-hand menu and select **Job**.
-You can use the default name, `job-1`, and click **Create**.
-
-In the job panel, set the **Schedule** to **Interval** and set it to run **Every 1 second**.
-
-Then configure the job:
-
-- **Resource**: `button-1`
-- **Method**: `DoCommand`
-- **Command**: `{ "action": "run_game_loop" }`
-
-Click save.
-
-Now, check the **LOGS** tab; you'll see the job triggered every second.
-
-{{% /tablestep %}}
-{{< /table >}}
-
-## Play the game
-
-As you've undoubtedly noticed the Viam UI is meant for testing, not for playing games.
-To give the game a better UI, we've created a small web application which is hosted as a Viam application.
-
-You can use this application to connect to your machine and play the game.
-Your machine must be online and configured before opening the app.
-
-[Take me to play the game](https://hello-world-game-web-app_naomi.viamapplications.com/).
-
-This tutorial does not cover creating the Viam application but you can check out the code [on GitHub](https://github.com/viam-labs/hello-world-game-module/tree/main/hello-world-game-web-app) and read up on [Viam applications](/operate/control/viam-applications/).
-
-## Conclusion
-
-Let's recap how the concepts you've learned in this tutorial work together in practice for the Desk Safari game:
-
-- **Your machine** (your laptop or desktop computer) runs the Viam software
-- A **component**, a webcam, provides access to a camera stream.
-- The publicly-available machine learning model that can identify items is run by a **service**.
-- Your machine has a **module** installed that provides the vision **service** which applies the machine learning model to the camera stream.
-- You've created a **module** containing a button **component** which starts and runs the control logic for the game.
-
-## Next steps
-
-You now know how to build a machine using {{< glossary_tooltip term_id="component" text="components" >}}, {{< glossary_tooltip term_id="service" text="services" >}}, and {{< glossary_tooltip term_id="module" text="modules" >}}.
-You can use these tools to **build any kind of machine** with Viam.
-
-If you want to continue working on your game, consider:
-
-- Building your own [Viam application, mobile app, or headless app.](/operate/control/viam-applications/)
-- Taking photos when an item is successfully detected by [capturing data from your machines](/data/capture-sync/capture-and-sync-data/)
-- [Training your own TF or TFLite model](/train/train-a-model/) to recognize more or other items
-
-## Troubleshooting
-
-### Camera not working
-
-- Check that your webcam is properly connected
-- Ensure no other applications are using the camera
-- Try restarting `viam-server`
-- See [Camera troubleshooting guide](/operate/reference/components/camera/webcam/#troubleshooting)
-
-### Module not loading
-
-- Verify the path to `run.sh` is correct
-- Review the **LOGS** tab for error messages
-
-### Game not detecting items
-
-- Ensure good lighting conditions
-- Hold items clearly in front of the camera
-- Reduce the **Minimum confidence threshold** in the vision service's attributes and use the vision service's **TEST** panel to check if it would detect the item at a lower confidence threshold.
-  If so, keep the lower value and update your value to also use the lower threshold instead of `0.5`.
-- If you cannot get the item to be recognized, the model may not work well enough.
-  Remove it from the `POSSIBLE_OPTIONS` or [train your own model](/train/train-a-model/).
-
-### Job or game logic not running
-
-- Confirm the cron schedule is set correctly (`* * * * * *`)
-- Check that the resource name matches exactly (`button-1`)
-- Verify the command format: `{ "action": "run_game_loop" }`
diff --git a/docs/operate/hello-world/what-is-viam.md b/docs/operate/hello-world/what-is-viam.md
deleted file mode 100644
index 6b5a29205a..0000000000
--- a/docs/operate/hello-world/what-is-viam.md
+++ /dev/null
@@ -1,159 +0,0 @@
----
-linkTitle: "What is Viam?"
-title: "What is Viam?"
-weight: 10
-layout: "docs"
-type: "docs"
-images: ["/general/understand.png"]
-imageAlt: "Viam platform overview"
-no_list: false
-description: "Viam is a software platform for building, deploying, and managing robotics applications."
-aliases:
-  - /operate/modules/basics/
-  - /operate/hello-world/quickstart/
-date: "2025-01-30"
----
-
-Viam is a software platform for building, deploying, and managing robotics applications.
-
-With Viam, you declare the hardware and services you need in a JSON config. Viam installs the drivers and any additional software modules required to support your configuration.
-Vision, motion planning, and most other capabilities you need are built in or available in the Viam module Registry, all with well-defined APIs to support your use case.
-Application code versioning, deployment, and rollback are native to the Viam platform.
-It's the development workflow you're used to, applied to physical devices.
-
-Viam brings software engineering practices to robotics: version control, remote monitoring and diagnostics, staged rollouts, and a registry of modules and models you can build on.
-
-## Viam fundamentals
-
-Every Viam machine starts with `viam-server`, Viam's service and package manager.
-Install `viam-server` with a single command.
-Then declare what hardware is connected and what services you need in a JSON config.
-`viam-server` pulls the necessary modules from the Viam Registry, launches required processes, and keeps them running to support all the hardware and services your application requires.
-`viam-server` also manages networking and data sync.
-
-The [Viam Registry](/operate/modules/configure-modules/) is a central repository of modules, ML models, and training scripts maintained by Viam and the robotics community.
-All registry assets support semantic versioning, enabling controlled deployment to individual robots and across your fleet.
-
-Registry modules provide drivers for cameras, motors, sensors, arms, and other hardware, plus services like object detection.
-`viam-server` also includes built-in services such as motion planning and data management.
-For machine learning, the Registry includes pretrained models for common tasks. You can also train and use your own models.
-
-Viam supports reusable configuration through [fragments](/manage/fleet/reuse-configuration/).
-Define a combination of components, services, and modules once, then apply that configuration across any number of machines.
-Use fragments to configure a camera-arm combination, a camera-to-object-detection pipeline, or an entire work cell.
-Fragments support variable substitution and per-machine overwrites, so you can deploy the same base configuration to hundreds of machines while accommodating site-specific settings.
-
-## Viam capabilities
-
-{{< alert title="In this section" color="note" >}}
-
-- [Get hardware running in minutes](#get-hardware-running-in-minutes)
-- [Operate from anywhere](#operate-from-anywhere)
-- [Capture data from edge to cloud](#capture-data-from-edge-to-cloud)
-- [Train and deploy models](#train-and-deploy-models)
-- [Develop code remotely](#develop-code-remotely)
-- [Manage software deployments](#manage-software-deployments)
-- [Scale easily](#scale-easily)
-- [Productize with Viam apps](#productize-with-viam-apps)
-
-{{< /alert >}}
-
-### Get hardware running in minutes
-
-Add a camera, motor, arm, or sensor to your JSON config with a few parameters: model, connection type, any device-specific settings.
-`viam-server` handles the rest—pulls the driver, initializes the device, and exposes it through a consistent API.
-You don't have to write device drivers or worry about dependencies.
-
-- **Consistent APIs across hardware:** All cameras expose the same interface regardless of manufacturer. Same for motors, sensors, arms, and other component types. Your code doesn't change when hardware does.
-- **Swap hardware without changing code:** Replace an Intel RealSense with an Orbbec Astra camera, or swap one motor controller for another—update the config and your application keeps working.
-- **Drivers for hundreds of devices:** The Registry includes modules for most common hardware. If yours isn't supported, write a module once and reuse it everywhere.
-
-### Operate from anywhere
-
-Connect to your machine from anywhere.
-No VPN, no port forwarding, no firewall configuration.
-Viam handles NAT traversal automatically.
-The web app, SDKs, and CLI all use the same connection infrastructure, so you can debug from your laptop and monitor from the Viam web app.
-
-- **Stream logs remotely:** View machine logs in the web app, filtered by level, keyword, or time range.
-- **Run code against remote hardware:** Write scripts on your laptop that connect to a machine over the network. Inspect component state, run diagnostics, or test behavior without deploying code.
-- **View live camera and sensor data:** See camera feeds and sensor readings in the web app's TEST panel for each component.
-- **Teleoperate from the browser:** Drive a base with keyboard controls, move an arm to specific positions, or reposition a gantry, all from the web UI.
-- **Visualize in 3D:** See a live 3D view of your machine showing component positions, camera feeds, and point clouds. Move components and watch the visualization update in real time.
-
-### Capture data from edge to cloud
-
-Configure [data capture](/data-ai/capture-data/) in JSON: which components, how often, what to keep.
-Viam handles the pipeline.
-Data syncs to the cloud when connectivity allows, survives network interruptions and restarts, and queues locally on devices with constrained bandwidth.
-No custom sync logic, no managing local storage, no worrying about edge cases.
-
-- **Capture from any component:** Record images from cameras, readings from sensors, or custom data from your own modules—all with configuration, no code required.
-- **Sync automatically:** Data syncs when bandwidth is available. If your machine goes offline, data queues locally and syncs when connectivity returns.
-- **Filter at the edge:** Reduce bandwidth and storage costs by filtering before sync. Keep only images with detections, sensor readings outside normal ranges, or samples at specified intervals.
-- **Query across your fleet:** Find data by machine, location, time range, component, or tags. Export for analysis or training.
-- **Manage storage automatically:** Set retention policies to delete old data. Configure local storage limits for edge devices with constrained disk space.
-
-### Train and deploy models
-
-[Train models](/data-ai/train/) on data you've captured, or bring models trained elsewhere.
-Deploy to your fleet with the same versioning and update mechanisms as code.
-
-- **Train in Viam:** Select captured data, annotate, choose a model architecture, and start a training job. No GPU provisioning, no training pipeline setup. Viam handles it.
-- **Bring your own model:** Import models trained in TensorFlow, PyTorch, ONNX, or other frameworks. Upload to the Registry and deploy like any other versioned asset.
-- **Deploy to your fleet:** Push a model to the Registry and configure machines to pull it. Pin to specific versions or allow automatic updates—same as modules.
-- **Run inference on device:** The ML model service runs on the machine. Inference happens locally without round-trips to the cloud.
-
-### Develop code remotely
-
-Traditional robotics development means standing next to the robot or SSH'ing into it.
-Viam lets you treat your robot like a machine in the cloud.
-Develop and test from your laptop.
-Your code connects to your robot machine over the network, through firewalls and NAT, without VPN.
-
-- **Iterate from your IDE:** Write code on your laptop, run it against your robot hardware over the network. No copying files, no deploy step. Just run and see results.
-- **Run on the robot machine when latency matters:** For tight control loops, run scripts directly on your robot machine. Same code, same APIs—just a different execution environment.
-- **Package as a module for production:** When you're ready, package your code as a module that `viam-server` manages: starts on boot, restarts on failure, reconfigures when settings change.
-- **Call built-in services from your code:** Motion planning, computer vision, navigation, and data capture are available as services you call from any SDK.
-
-### Manage software deployments
-
-Package your control logic as a [module](/operate/modules/write-a-logic-module/) and deploy through the Viam Registry for version control, remote updates, and fleet-wide rollouts.
-No cross-compiling.
-Viam handles everything.
-
-- **Managed lifecycle:** `viam-server` manages dependencies and ensures your application code starts on boot and restarts when necessary.
-- **Reconfigure on the fly:** Tune the application parameters you define with configuration updates in the Viam app. Changes apply within seconds. No restarts or redeployment.
-- **Version control:** Pin machines to exact versions for stability, or allow automatic updates at the patch, minor, or major level.
-- **OTA updates:** Push new versions to the registry with the CLI; machines pull updates automatically per their update policies.
-
-### Scale easily
-
-Your prototype configuration becomes your production configuration.
-Turn a working machine setup into a [fragment](/manage/fleet/reuse-configuration/) and apply it to several, dozens, or even hundreds of machines.
-No deployment scripts, no copying files, no per-machine setup.
-
-- **Create a fragment from your prototype:** Once your machine works, export the configuration as a fragment. That exact setup is now reusable across any number of machines. Viam handles provisioning.
-- **Update configurations fleet-wide:** Change a fragment and every machine using it pulls the update. No scripting, no SSH loops.
-- **Override per-machine differences:** If some machines have a different camera model or site-specific parameter value, override for just those machines without forking the base fragment.
-- **Roll out changes incrementally:** Deploy configuration changes, module versions, or ML models to a subset of machines first. Validate before rolling out fleet-wide.
-- **Roll back with one change:** Viam maintains configuration history. Revert to a previous version of a fragment, module, or model with a single update.
-
-### Productize with Viam apps
-
-Building a robotics product means building customer infrastructure—auth systems, dashboards, billing.
-Viam provides these so you can focus on your product.
-
-- **White-label authentication:** Customers authenticate through a login screen with your logo and branding, not Viam's.
-- **Build customer-facing apps:** Use the TypeScript SDK for web dashboards or the Flutter SDK for iOS and Android apps. Both handle authentication and provide access to all component and service APIs.
-- **Built-in billing:** Define pricing tiers—per-machine fees, data costs, or both. Viam handles invoicing and payment collection.
-
-## Next steps
-
-Now you know about the most important concepts for using Viam.
-
-We recommend putting these concepts into practice by following the [Desk Safari tutorial](/operate/hello-world/tutorial-desk-safari/) to build your first machine.
-
-If you'd like to learn more about Viam and how it works, see [Viam architecture](/operate/reference/architecture/).
-
-For more information on cloud capabilities like fleet management and provisioning, see [Monitor Air Quality with a Fleet of Sensors](/tutorials/control/air-quality-fleet/).
diff --git a/docs/operate/install/_index.md b/docs/operate/install/_index.md
deleted file mode 100644
index 70e3f9c6e2..0000000000
--- a/docs/operate/install/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Installation"
-weight: 100
-layout: "empty"
-type: "docs"
-empty_node: true
-open_on_desktop: true
-header_only: true
-canonical: "/operate/install/setup/"
----
diff --git a/docs/operate/install/setup-micro/_index.md b/docs/operate/install/setup-micro/_index.md
deleted file mode 100644
index fcb9902589..0000000000
--- a/docs/operate/install/setup-micro/_index.md
+++ /dev/null
@@ -1,403 +0,0 @@
----
-linkTitle: "Set up an ESP32"
-title: "Set up an ESP32"
-weight: 25
-layout: "docs"
-type: "docs"
-images: ["/installation/thumbnails/install.png"]
-imageAlt: "Install Viam"
-no_list: false
-description: "Install the lightweight version of the software that drives hardware and connects your device to the cloud."
-aliases:
-  - /installation/microcontrollers/
-  - /installation/prepare/microcontrollers/
-  - /installation/prepare/microcontrollers/
-  - /build/micro-rdk/
-  - /get-started/installation/microcontrollers/
-  - /installation/viam-micro-server-setup/
-  - /operate/reference/viam-micro-server/viam-micro-server-troubleshooting/
-  - /operate/get-started/setup-micro/
----
-
-Viam maintains a [lightweight version of `viam-server`](/operate/reference/viam-micro-server/) for microcontrollers.
-
-## Supported microcontrollers
-
-To work with Viam's Micro-RDK, ESP32 microcontrollers must have at least:
-
-- 2 cores
-- 384kB SRAM
-- 2MB PSRAM
-- 8MB flash
-
-The following microcontrollers have been tested with Viam:
-
-- [ESP32-WROVER Series](https://www.espressif.com/en/products/modules/esp32)
-
-{{% hiddencontent %}}
-The Micro-RDK and `viam-micro-server` do not support 32-bit Linux.
-{{% /hiddencontent %}}
-
-## About ESP32 microcontroller setup
-
-Microcontrollers do not run operating systems and are instead flashed with dedicated firmware.
-Because of this, the microcontroller setup process is different than for SBCs, laptops, and desktops.
-
-To use an ESP32 controller with custom hardware, you build a firmware version from the Micro-RDK and modules to support your hardware.
-
-To quickly try out Viam for microcontrollers, you can use the pre-built binary `viam-micro-server` which supports the following components:
-
-- [`gpio`](/operate/reference/components/servo/gpio-micro-rdk/): A servo controlled by GPIO pins.
-- [`two_wheeled_base`](/operate/reference/components/base/two_wheeled_base/): A robotic base with differential steering.
-- [`free_heap_sensor`](https://github.com/viamrobotics/micro-rdk/tree/main/examples/modular-drivers/src): Reports the amount of free heap memory on the microcontroller.
-- [`wifi_rssi_sensor`](https://github.com/viamrobotics/micro-rdk/tree/main/examples/modular-drivers/src): Reports the signal strength of the ESP32's WiFi connection.
-
-## Quickstart with pre-built firmware
-
-{{% hiddencontent %}}
-Viam provides installers to flash an ESP32 from macOS or Linux running on the x86_64 or ARM64 (AArch64) processor architectures.
-{{% /hiddencontent %}}
-
-To get started quickly with the pre-built `viam-micro-server` binary, follow these steps:
-
-1. Create a Viam account on [app.viam.com](https://app.viam.com).
-   You can configure and manage devices and data collection in the web UI.
-
-1. Add a new _{{< glossary_tooltip term_id="machine" text="machine" >}}_ using the button in the top right corner of the **LOCATIONS** tab in the app.
-   A machine represents your device.
-
-1. On your machine's page, click **View setup instructions** and follow the steps for your operating system.
-   The app provides commands to install `viam-micro-server` and connect it to the cloud with your machine's unique credentials.
-
-1. A secure connection is automatically established between your machine and Viam.
-   When you update your machine's configuration, `viam-micro-server` automatically gets the updates.
-
-   You are ready to [configure](#configure-and-test-your-machine) any of the components listed above on your machine.
-
-## Build and flash custom firmware
-
-If you are using your ESP32 with resources that are not supported by the pre-built binary, you can build your own firmware with the Micro-RDK and your choice of {{< glossary_tooltip term_id="module" text="modules" >}}.
-
-### Set up your development environment
-
-The [Micro-RDK](https://github.com/viamrobotics/micro-rdk) (from which `viam-micro-server` is built) is written in Rust.
-To be able to develop for the Micro-RDK on macOS and Linux systems, you must install the following software on your development machine:
-
-1. Install dependencies:
-
-   {{< tabs >}}
-   {{% tab name="Linux" %}}
-
-   ```sh { class="command-line" data-prompt="$"}
-   sudo apt-get install bison ccache cmake curl dfu-util flex git gperf libffi-dev libssl-dev libudev-dev libusb-1.0-0 ninja-build python3 python3-pip python3-venv wget
-   ```
-
-   {{% /tab %}}
-   {{% tab name="macOS" %}}
-
-   If you haven't already, [install Homebrew](https://brew.sh/).
-
-   Then, install dependencies:
-
-   ```sh { class="command-line" data-prompt="$"}
-   brew install cmake dfu-util ninja
-   ```
-
-   {{% /tab %}}
-   {{< /tabs >}}
-
-1. If you do not yet have a Rust environment installed, install it with `rustup`.
-
-   ```sh { class="command-line" data-prompt="$"}
-   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
-   ```
-
-   Once completed, start a new shell instance, or run `. "$HOME/.cargo/env"` in the current one.
-
-   See the [Rust Installation guide](https://www.rust-lang.org/tools/install) for more information and other installation methods.
-
-1. Install `espup` and ESP development utilities with `cargo`:
-
-   ```sh { class="command-line" data-prompt="$"}
-   cargo install cargo-espflash cargo-generate espflash espup ldproxy
-   ```
-
-1. Use `espup` to download and install the ESP Rust toolchain:
-
-   ```sh { class="command-line" data-prompt="$"}
-   espup install -s -f /dev/null -v 1.85.0
-   ```
-
-{{% hiddencontent %}}
-Prior versions of the above `espup` instructions created a file called `export-rs.sh` which needed to be sourced before proceeding.
-That requirement [no longer applies](https://github.com/esp-rs/esp-idf-hal/issues/319#issuecomment-1785168921) for Micro-RDK development.
-The above command redirects `espup`'s production of the setup script to `/dev/null` to avoid cluttering the home directory.
-If you would like to instead retain the setup script, replace `/dev/null` in the above command with the location where you would like the script to be written, or remove the `-f /dev/null` entirely and the file will be written to `$HOME/export-esp.sh` by default.
-{{% /hiddencontent %}}
-
-### Build your firmware
-
-Create firmware that integrates an existing module with the Micro-RDK:
-
-1. Create a new machine and obtain its credentials:
-
-   Add a new machine on [Viam](https://app.viam.com).
-   Click on the name of the machine to go to the machine's page, then select the **CONFIGURE** tab.
-
-   Then select the part status dropdown to the right of your machine's name on the top of the page and copy the **Machine cloud credentials**:
-
-   {{<imgproc src="/get-started/micro-credentials.png" resize="450x" declaredimensions=true alt="Machine part info menu accessed by Live status indicator, with machine cloud credentials button highlighted." class="shadow" >}}
-
-   The Micro-RDK needs these credentials, which contain your machine part secret key and cloud app address, to connect to Viam.
-
-1. Generate a new project skeleton from [this template](https://github.com/viamrobotics/micro-rdk/tree/main/templates/project):
-
-   ```sh { class="command-line" data-prompt="$"}
-   cargo generate --git https://github.com/viamrobotics/micro-rdk.git
-   ```
-
-   Follow the prompts:
-
-   - Which sub-template should be expanded?: `templates/project`.
-   - Project name: Your choice.
-   - MCU: `esp32`.
-   - Include camera module?: If you will use an `esp32-camera` or a `fake` camera as a component of your machine, select `true`.
-   - Machine cloud credentials: Paste in the machine cloud credentials you obtained in step 1.
-   - Enter Wi-Fi name: The name of the Wi-Fi network for the ESP32 to connect to on boot. Note that you must provide a 2.4 GHz network.
-   - Enter the Wi-Fi password: The password for the 2.GHz WiFi network.
-
-   Hit **Enter** to generate the project.
-   The CLI automatically initializes a git repository in the generated directory for version control.
-
-1. Navigate into the generated project:
-
-   ```sh { class="command-line" data-prompt="$"}
-   cd <path-to/your-project-directory>
-   ```
-
-1. Add any desired modules to the project by including them in the `dependencies` section of the `Cargo.toml` for the generated project:
-
-   {{< tabs >}}
-   {{% tab name="Local path dependency" %}}
-
-   While developing a module, you'll typically use a local path dependency to reference your module directory, for example:
-
-   ```toml {class="line-numbers linkable-line-numbers" data-line="3"}
-   [dependencies]
-   ...
-   my-module = { path = "../my-module" }
-   ```
-
-   {{% /tab %}}
-   {{% tab name="Git repository dependency" %}}
-
-   For modules hosted in a Git repository, specify the repository URL and optionally a specific commit (`rev`), branch (`branch`), or tag (`tag`), for example:
-
-   ```toml {class="line-numbers linkable-line-numbers" data-line="3"}
-   [dependencies]
-   ...
-   my-module = { git = "https://github.com/username/my-module.git", tag = "v1.0.0" }
-   ```
-
-   To use any of the [example modules](https://github.com/viamrobotics/micro-rdk/blob/main/examples/modular-drivers/README.md#example-modules) provided by Viam, use this line, specifying the Micro-RDK version that matches your development environment:
-
-   ```toml {class="line-numbers linkable-line-numbers" data-line="3"}
-   [dependencies]
-   ...
-   micro-rdk-modular-driver-example = { git = "https://github.com/viamrobotics/micro-rdk.git", rev = "v0.5.0", package = "micro-rdk-modular-driver-example", features = ["esp32"] }
-   ```
-
-   {{% /tab %}}
-   {{< /tabs >}}
-
-1. Compile the project:
-
-   ```sh { class="command-line" data-prompt="$"}
-   make build-esp32-bin
-   ```
-
-   The first build can take a few minutes, as ESP-IDF must be cloned and built, and all dependent Rust crates must be fetched and built.
-   Subsequent builds will be faster.
-
-### Flash your ESP32
-
-Upload the generated firmware to your ESP32:
-
-1. Use a data cable to connect your ESP32 board to a USB port on your development machine.
-
-1. Run the following command to flash the firmware to your ESP32:
-
-   ```sh { class="command-line" data-prompt="$"}
-   make flash-esp32-bin
-   ```
-
-   When prompted, select the serial port that your ESP32 is connected to through a data cable.
-
-   If the flash is successful, you will retain a serial connection to the board until you press `Ctrl-C`.
-   While the serial connection is live, you can also restart the currently flashed image with `Ctrl-R`.
-
-1. Navigate to your new machine's page.
-   If successful, the status indicator should turn green and show the **Live** status.
-
-### Configure and test your machine
-
-You can now configure the models you included in your firmware and test them:
-
-1. Navigate to your machine's page.
-
-1. From the **CONFIGURE** tab, click **JSON** mode.
-   Micro-RDK components and services must be configured in JSON.
-
-1. Add your components and services to the machine configuration.
-   If you are using one of the example modules, find configuration details in the [example modules README](https://github.com/viamrobotics/micro-rdk/blob/main/examples/modular-drivers/README.md#example-modules).
-   For example, if you want to use a free heap sensor, your configuration could look like this:
-
-   ```json
-   {
-     "components": [
-       {
-         "name": "my-free-heap-sensor",
-         "api": "rdk:component:sensor",
-         "model": "free-heap",
-         "attributes": {}
-       }
-     ]
-   }
-   ```
-
-1. Click **Builder** mode and find the configuration card of the component you want to test.
-
-1. Click to open the **Test** section of the card and use the interface to test the component.
-
-1. If you make changes to your module code, rerun the build and flash steps to update the firmware and test the new version on your ESP32.
-
-## Configure over-the-air updates
-
-You can update the firmware on your microcontroller without a physical connection.
-
-{{% hiddencontent %}}
-Over-the-air updates are available for `viam-server` and the Micro-RDK. For information about `viam-server` see [Deploy software packages to machines](/manage/software/deploy-software/).
-The following information covers the Micro-RDK.
-{{% /hiddencontent %}}
-
-The first time you flash your microcontroller, you must build a full firmware image, and use a data cable to flash it to your microcontroller.
-After the initial flash, you can update the firmware remotely by using the over-the-air (OTA) service to pull [cloud-hosted, OTA-ready firmware](#build-and-host-ota-firmware) from a URL.
-
-The firmware hosting endpoint must use HTTP/2.
-
-To configure OTA updates:
-
-1. On your machine's page, go to the **CONFIGURE** tab and select **JSON** mode.
-
-1. Paste in the template below, then configure the URL from which to fetch new firmware, and a version name of your choice.
-   The value of the `version` field is not directly used by the OTA service, so you can use any string.
-
-   {{< tabs >}}
-   {{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers" data-line="3-11"}
-{
-  "services": [
-    {
-      "name": "OTA",
-      "api": "rdk:service:generic",
-      "model": "rdk:builtin:ota_service",
-      "attributes": {
-        "url": "<URL where firmware is stored in cloud storage>",
-        "version": "<version name>"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "services": [
-    {
-      "name": "OTA",
-      "api": "rdk:service:generic",
-      "model": "rdk:builtin:ota_service",
-      "attributes": {
-        "url": "https://github.com/Jessamy/modulefirmware/releases/download/v0.1.2/modulefirmware-ota.bin",
-        "version": "myVersion1"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Your device checks for configuration updates periodically.
-If the device receives a configuration with a modified `version` field, the device downloads the new firmware to an inactive partition and restarts.
-When the device boots it loads the new firmware.
-
-To trigger a remote update of the firmware on your microcontroller after the initial configuration, edit the `version` field and save the config.
-
-{{% alert title="Note" color="note" %}}
-There is no way to roll back to previous firmware after a bad upgrade without reflashing the device with a physical connection, so test your firmware thoroughly before deploying it to a fleet.
-{{% /alert %}}
-
-### Update multiple microcontrollers at the same time
-
-To update the firmware version for a group of microcontrollers at the same time, you can [create a fragment](/manage/software/deploy-software/) with the OTA service configuration and apply it to multiple machines.
-Then, whenever you update the `version` field in the fragment, the version will be updated for each machine that has that fragment in its config, triggering a firmware update the next time the devices fetch their configs.
-
-### Build and host OTA firmware
-
-To use the OTA service, you must host your firmware in the cloud so that it can be accessed at a URL.
-
-GitHub workflows simplify the process of building and hosting your firmware by eliminating the need to build locally and then upload the firmware image to a cloud storage bucket.
-
-{{< tabs >}}
-{{% tab name="Use GitHub workflows (recommended)" %}}
-
-To build firmware on GitHub, follow these steps:
-
-1. [Create a firmware project](#build-and-flash-custom-firmware).
-   _Do not include Wi-Fi credentials or machine cloud credentials in the project_, since you will be publishing the project to a public GitHub repository.
-   The OTA service does not modify the partition containing the machine cloud credentials and WiFi credentials, so OTA updates do not require the credentials.
-
-1. Create a public GitHub repository for your firmware project, and upload the contents of the firmware project directory to the repository.
-   The `templates/project` template you used to create your project contains a GitHub workflow file that is used to build your firmware.
-
-1. In the firmware GitHub repository, navigate to **Settings** &rarr; **Actions** &rarr; **General** and enable **Read and write permissions**.
-
-1. Go to the firmware GitHub repository's **Releases** page and create a new release.
-   Create a tag starting with `v` followed by a version number, for example `v1.0.0`.
-   Click **Publish release** to trigger a build of the firmware.
-
-To deploy the firmware:
-
-1. Wait for the build to complete.
-
-1. In your firmware GitHub repository, navigate to the **Releases** page and find the assets for the release you just created.
-   The assets include the full and OTA firmware images.
-   Copy the URL of the OTA firmware image.
-
-1. Navigate to your machine's **CONFIGURE** tab and [configure the OTA service](#configure-over-the-air-updates) with the URL of the firmware image you just copied.
-
-{{% /tab %}}
-{{% tab name="Build locally and host manually" %}}
-
-If you want to use OTA updates, but don't want to use GitHub Actions, follow these steps:
-
-1. Build the OTA firmware locally with the following command:
-
-   ```sh { class="command-line" data-prompt="$"}
-   make build-esp32-ota
-   ```
-
-   Note that this is different from the `make build-esp32-bin` command, which builds a full firmware image that you must use the first time you flash your microcontroller.
-
-1. Upload the OTA firmware image to a cloud storage bucket.
-
-1. Configure the URL of the cloud storage bucket in your microcontroller's OTA service configuration.
-
-{{% /tab %}}
-{{< /tabs >}}
diff --git a/docs/operate/install/setup-micro/micro-troubleshooting.md b/docs/operate/install/setup-micro/micro-troubleshooting.md
deleted file mode 100644
index 8e629533de..0000000000
--- a/docs/operate/install/setup-micro/micro-troubleshooting.md
+++ /dev/null
@@ -1,220 +0,0 @@
----
-title: "Micro-RDK Troubleshooting"
-linkTitle: "Micro-RDK Troubleshooting"
-weight: 100
-type: docs
-images: ["/installation/thumbnails/install.png"]
-imageAlt: "Install viam-micro-server"
-description: "Troubleshooting tips and best practices for installing and using viam-micro-server or other Micro-RDK-based firmware on a microcontroller."
-aliases:
-  - /operate/reference/viam-micro-server/viam-micro-server-setup/
-  - /operate/reference/viam-micro-server/micro-troubleshooting/
-  - /operate/get-started/setup-micro/micro-troubleshooting/
-# date: "2024-10-07"
-# updated: ""  # When the content was last entirely checked
----
-
-{{% alert title="Tip" color="tip" %}}
-The [Viam Micro-RDK installer](https://github.com/viamrobotics/micro-rdk/tree/main/micro-rdk-installer) is a command line tool that can be helpful for troubleshooting.
-{{% /alert %}}
-
-## Installation issues
-
-### Error: `xtensa-esp32-elf-gcc: error: unrecognized command line option '--target=xtensa-esp32-espidf'` when building on macOS
-
-This is caused by an [upstream bug](https://github.com/esp-rs/esp-idf-template/issues/174).
-To work around this issue, ensure that `CRATE_CC_NO_DEFAULTS=1` is set in the environment when building.
-
-### Error: `error: externally-managed-environment` when building ESP-IDF on macOS
-
-This is encountered when attempting to build ESP-IDF projects while using Python obtained from Homebrew.
-Homebrew's Python infrastructure is not intended for end-user consumption but is instead made available to support Homebrew packages which require a python interpreter.
-The preferred workaround for this issue is to obtain a user-facing python installation not from Homebrew, but there are other, less safe, workarounds.
-Please see the macOS specific notes in the [development technical notes on GitHub](https://github.com/viamrobotics/micro-rdk/blob/main/DEVELOPMENT.md#fixing-esp-builds-on-macos) for more details.
-
-### Error: Failed to open serial port
-
-If you run into the error `Failed to open serial port` when flashing your ESP32 with Linux, make sure the user is added to the group `dialout` with `sudo gpasswd -a $USER dialout`.
-
-### Error: `espflash::timeout`
-
-If you get the following error while connecting to your ESP32:
-
-```sh { class="command-line" data-prompt="$"}
-`Error: espflash::timeout
-
-  × Error while connecting to device
-  ╰─▶ Timeout while running command
-```
-
-Run the following command, replacing `<YOUR_PROJECT_NAME>` with the name of your project firmware (for example, `esp32-camera`):
-
-```sh { class="command-line" data-prompt="$"}
-espflash flash --erase-parts nvs --partition-table partitions.csv  target/xtensa-esp32-espidf/release/<YOUR_PROJECT_NAME> --baud 115200 && sleep 2 && espflash monitor
-```
-
-Try the connection command again.
-The baud rate on your device may not have been fast enough to connect.
-If successful, Viam will show that your machine part's status is **Live**.
-
-You can also try disconnecting and reconnecting the ESP32 to the USB port, then retrying the flash command.
-
-### Error: `viam.json` not found
-
-If you get the error `viam.json not found` try the following to manually add your machine cloud credentials as a file in your project:
-
-1. Navigate to your machine's page and select the **CONFIGURE** tab.
-1. Select the part status dropdown to the right of your machine's name on the top of the page:
-
-   {{<imgproc src="/get-started/micro-credentials.png" resize="450x" declaredimensions=true alt="Machine part info menu accessed by Live status indicator, with machine cloud credentials button highlighted." class="shadow" >}}
-
-1. Click the copy icon underneath **Machine cloud credentials**.
-   The Micro-RDK needs this JSON object, which contains your machine part secret key and cloud app address, to connect to Viam.
-1. Navigate to the directory of the project you just created.
-1. Create a new <file>viam.json</file> file and paste the machine cloud credentials in.
-1. Save the file.
-
-### Error: failed to run custom build command for `esp32-explorer (/host)`
-
-This may occur for various reasons such as your machine cloud credentials, Wi-Fi SSID, or password not being populated.
-Check that your project directory contains machine cloud credentials in a <file>viam.json</file>, and that you provided Wi-Fi credentials.
-
-### Error: invalid value `460800` for `--before <BEFORE>`
-
-Change `"-b"` to `"-B` in the <file>Makefile</file>, as `"-B"` is the Baudrate config.
-Run the following commands to flash <file>esp32-server.bin</file> to your ESP32 microcontroller at a high baud rate, wait for 2 seconds, and observe the device's output:
-
-```sh {class="command-line" data-prompt="$"}
-espflash write-bin 0x0 target/esp32-server.bin -B 460800  && sleep 2 && espflash monitor
-```
-
-## Other issues
-
-### Unstable connection
-
-Because microcontrollers are more resource-constrained than single-board computers or other computers, when you run [control code](/reference/sdks/) to control your Micro-RDK machine, you may experience instability.
-If your connection is unstable, we recommend changing the default settings by making the following changes to your connection code.
-This code will disable the SDK background task that monitors the connection to your machine, reducing processing demands and improving the reliability of connection establishment.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-# TODO: Replace this with the connect function on the CONNECT tab
-async def connect():
-    opts = RobotClient.Options(
-        # viam-micro-server configures once at boot,
-        # so we don't need to check if the components have changed
-        refresh_interval=0,
-        # Checking the connection can safely be disabled
-        check_connection_interval=0,
-        # Same for Attempting to reconnect
-        attempt_reconnect_interval=0,
-        # viam-micro-server doesn't support sessions
-        # so it is safe to disable them
-        disable_sessions=True,
-        dial_options=DialOptions.with_api_key(
-            # TODO: Replace "<API-KEY-ID>" (including brackets)
-            # with your machine's API key ID
-            api_key_id='<API-KEY-ID>',
-            # TODO: Replace "<API-KEY>" (including brackets)
-            # with your machine's API key
-            api_key='<API-KEY>')
-    )
-    # TODO: Replace "<MACHINE-ADDRESS>" (including brackets) with address from
-    # the CONNECT tab.
-    return await RobotClient.at_address('<MACHINE-ADDRESS>', opts)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-// TODO: Replace the call to client.New with the following block
-robot, err := client.New(
-    context.Background(),
-    "<MACHINE-ADDRESS>", // TODO: Replace "<MACHINE-ADDRESS>" (including brackets) with address from the CONNECT tab.
-    logger,
-    client.WithDisableSessions(), // viam-micro-server doesn't support sessions so it is safe to disable them
-    client.WithCheckConnectedEvery(0), // Checking the connection can safely be disabled
-    client.WithReconnectEvery(0), // Same for Attempting to reconnect
-    client.WithRefreshEvery(0), // viam-micro-server configures once at boot, so we don't need to check if the components have changed
-    client.WithDialOptions(rpc.WithEntityCredentials(
-        // TODO: Replace "<API-KEY-ID>" (including brackets) with your machine's
-        // API key ID
-        "<API-KEY-ID>",
-        rpc.Credentials{
-            Type: rpc.CredentialsTypeAPIKey,
-            // TODO: Replace "<API-KEY>" (including brackets) with your
-            // machine's API key
-            Payload: "<API-KEY>",
-        })),
-    )
-if err != nil {
-    logger.Fatal(err)
-}
-
-```
-
-{{% /tab %}}
-{{% /tabs %}}
-
-### Error: IceTransportClosed
-
-If you are trying to connect to an ESP32 and the connection is unstable with the repeating error `E (412486) micro_rdk::common::webrtc::ice: closing ice agent with error IceTransportClosed`, you have opened too many connections to the ESP32, which has a maximum of 3 connections by default.
-Make sure you only have one tab with your machine's page open to limit the number of connections to your ESP32.
-
-### Linux port permissions
-
-If a "Permission Denied" or similar port error occurs, first check the connection of the ESP32 to the machine's USB port.
-If connected and the error persists, run `sudo usermod -a -G dialout $USER` to add the current user to the `dialout` group, restart your terminal, and try again.
-
-### macOS executable permissions
-
-When using a machine running a version of macOS, the user is blocked from running the executable by default.
-To fix this, **Control+Click** the binary in Finder and then, in the following two prompts select **Open**.
-Close whatever terminal window this opens to be able to run the installer.
-
-### Error: FlashConnect
-
-This may occur because the serial port chosen if/when prompted is incorrect.
-However, if the correct port has been selected, try the following:
-
-1. Run the installer as explained above.
-2. When prompted to select a serial port:
-   1. Hold down the "EN" or enable button on your ESP32.
-   2. With the above button held down, select the correct serial port.
-   3. Press and hold down the "EN" and "Boot" buttons at the same time. Then release both.
-
-If this doesn't work, try wiggling or reattaching the connections on both ends of the data cable connecting your ESP32 to your computer.
-You can also try using a different cable entirely; make sure it is a data-compatible cable.
-
-### Ubuntu not recognizing the microcontroller
-
-If you’re trying to connect a microcontroller using serial port to an Ubuntu system and the computer doesn’t seem to be recognizing the microcontroller, check if the `brltty` service or its secondary service `brltty-udev` are active (`brltty` is a service installed by default that provides access to a braille display):
-
-```sh {class="command-line" data-prompt="$" data-output="2"}
-sudo systemctl status | grep brltty
-brltty-udev.service loaded active running Braille Device Support
-```
-
-It is a known issue that this service takes ownership of cp210x devices that are used in serial communication with microcontrollers.
-
-To disable the services, run the following:
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl stop brltty-udev.service
-sudo systemctl mask brltty-udev.service
-sudo systemctl stop brltty.service
-sudo systemctl disable brltty.service
-```
-
-You may also need to reboot your system, and/or unplug the cable from the computer and re-plug it in.
-
-See this [blog post](https://koen.vervloesem.eu/blog/how-to-stop-brltty-from-claiming-your-usb-uart-interface-on-linux/) and [Ubuntu bug report](https://bugs.launchpad.net/ubuntu/+source/brltty/+bug/1958224) for more.
-
-### Additional assistance
-
-You can find general Viam troubleshooting information in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
-
-{{< snippet "social.md" >}}
diff --git a/docs/operate/install/setup.md b/docs/operate/install/setup.md
deleted file mode 100644
index 4a81033265..0000000000
--- a/docs/operate/install/setup.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-linkTitle: "Set up a computer or SBC"
-title: "Set up a computer or single-board computer (SBC)"
-weight: 20
-layout: "docs"
-type: "docs"
-images: ["/installation/thumbnails/install.png"]
-imageAlt: "Install Viam"
-no_list: false
-description: "Install the software that drives hardware and connects your device to the cloud."
-aliases:
-  - /installation/viam-server-setup/
-  - /how-tos/configure/
-  - /installation/prepare/
-  - /installation/macos-install/
-  - /installation/linux-install/
-  - /installation/install/
-  - /installation/install/linux-install/
-  - /installation/install/macos-install
-  - /getting-started/installation/
-  - /getting-started/macos-install/
-  - /getting-started/linux-install/
-  - /installation/
-  - /get-started/installation/
-  - /operate/get-started/setup/
-date: "2025-10-16"
----
-
-Get started by installing [`viam-server`](/operate/reference/viam-server/), the open-source software that drives your hardware and connects your device to the cloud.
-
-## Prerequisite: Install operating system
-
-If you're using Viam with a single-board computer (SBC) that does not yet have a Linux operating system installed, start by flashing an OS.
-For convenience, we provide operating system installation instructions for some popular SBCs:
-
-{{< cards >}}
-{{% card link="/operate/reference/prepare/rpi-setup/" class="small" %}}
-{{% card link="/operate/reference/prepare/odroid-c4-setup/" class="small" %}}
-{{% card link="/operate/reference/prepare/orange-pi-3-lts/" class="small" %}}
-{{% card link="/operate/reference/prepare/orange-pi-zero2/" class="small" %}}
-{{% card link="/operate/reference/prepare/beaglebone-setup/" class="small" %}}
-{{% card link="/operate/reference/prepare/jetson-agx-orin-setup/" class="small" %}}
-{{% card link="/operate/reference/prepare/jetson-nano-setup/" class="small" %}}
-{{% card link="/operate/reference/prepare/pumpkin/" class="small" %}}
-{{% card link="/operate/reference/prepare/sk-tda4vm/" class="small" %}}
-{{< /cards >}}
-
-If your SBC or other computer already has a supported operating system installed, you can skip to [Install `viam-server`](#install-viam-server).
-Check if your system can run `viam-server` by running the following command in your terminal:
-
-{{< tabs >}}
-{{% tab name="Linux" %}}
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-arch=$(uname -m); bits=$(getconf LONG_BIT); [[ (("$arch" == "x86_64" || "$arch" == "aarch64") && "$bits" == "64") || "$arch" == "armv7l" ]] && echo "✅ Your system can run viam-server" || echo "❌ Your system cannot run viam-server"
-```
-
-`viam-server` can run on Linux 64-bit operating systems running on AArch64 (ARM64) or x86-64 architectures.
-Support for Linux Armv7l is in beta.
-
-{{% /tab %}}
-{{% tab name="macOS" %}}
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-bash -c '[[ "$(uname -s)" == "Darwin" && ("$(uname -m)" == "x86_64" || "$(uname -m)" == "arm64") ]] && echo "✅ Your system can run viam-server" || echo "❌ Your system cannot run viam-server"'
-```
-
-{{% alert title="Note for Mac users" color="note" %}}
-`viam-server` can run on Macs, but not all {{< glossary_tooltip term_id="module" text="modules" >}} support Macs.
-{{% /alert %}}
-
-{{% /tab %}}
-{{% tab name="Windows" %}}
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-(Get-WmiObject -Class Win32_OperatingSystem).OSArchitecture -eq "64-bit" -and (wsl --status 2>$null) -ne $null ? "✅ Your system can run viam-server" : "❌ Your system needs WSL for viam-server"
-```
-
-{{% alert title="Windows note" color="note" %}}
-`viam-server` can run on Windows Subsystem for Linux (WSL), but WSL itself does not currently support exposing many types of Windows hardware to the embedded Linux kernel.
-This means that some hardware, such as a connected webcam, may not be available to `viam-server` with WSL, even though it is fully supported for native Linux systems.
-
-- Native: Use native if you are using a WSL version prior to WSL 2 or need native USB support
-- WSL: Use WSL if you are using Python modules or other Linux dependencies
-
-{{% /alert %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-For 32-bit microcontrollers, see [Set up an ESP32](/operate/install/setup-micro/).
-
-## Install `viam-server`
-
-Install `viam-server` on the computer or single-board computer (SBC) that is directly connected to your hardware (for example sensors, cameras, or motors).
-
-1. Make sure your computer or SBC is powered on and connected to the internet.
-
-1. Create a Viam account on [app.viam.com](https://app.viam.com).
-   You can configure and manage devices and data collection in the web UI.
-
-1. Create a new _{{< glossary_tooltip term_id="machine" text="machine" >}}_ using the **Add machine** button in the top right corner of the **LOCATIONS** tab in the app.
-   A machine represents your device.
-
-1. On your machine's page, click **View setup instructions** and follow the steps for your operating system.
-   The app provides commands to install `viam-server` and connect it to the cloud with your machine's unique credentials.
-
-1. After you install `viam-server`, a secure connection is automatically established between your machine and Viam.
-   When you update your machine's configuration, `viam-server` automatically gets the updates.
-
-   You are ready to [configure supported hardware](/operate/modules/configure-modules/) on your machine.
-
-## Try an example
-
-{{< readfile "/static/include/install/try-example.md" >}}
-
-{{% hiddencontent %}}
-
-## Installation methods: `viam-agent` versus manual
-
-`viam-agent` is a service manager that automatically updates `viam-server` and includes tools for [provisioning your devices](/manage/fleet/provision/setup/), networking, and configuring operating system settings.
-
-When you set up a Linux device with Viam, you can use `viam-agent`, or to manually install only `viam-server`.
-Using `viam-agent` is generally recommended when installing `viam-server`.
-
-When you set up a native Windows device with Viam, you must use the [Viam Agent installer](https://storage.googleapis.com/packages.viam.com/apps/viam-agent/viam-agent-stable.msi).
-
-`viam-agent` is not available for macOS, Windows Subsystem for Linux (WSL), or microcontrollers.
-Use manual install for those systems.
-{{% /hiddencontent %}}
-
-{{% hiddencontent %}}
-
-## Running `viam-agent` or `viam-server` in a docker container
-
-We do not recommend running `viam-server` or `viam-agent` in Docker.
-If you need to use Docker reach out to [support](mailto:support@viam.com).
-
-{{% /hiddencontent %}}
-
-{{% hiddencontent %}}
-On Linux installs, by default `viam-server` or `viam-agent` and `viam-server` will start automatically when your system boots.
-On macOS installs, `viam-server` does not start automatically on boot.
-You can change this behavior if desired.
-
-To learn how to run, update, or uninstall `viam-agent`, see [Manage `viam-agent`](/manage/reference/viam-agent/manage-viam-agent/).
-
-For manual installs of only `viam-server`, see [Manage `viam-server`](/operate/reference/viam-server/manage-viam-server/).
-{{% /hiddencontent %}}
diff --git a/docs/operate/modules/_index.md b/docs/operate/modules/_index.md
deleted file mode 100644
index 1643c32b75..0000000000
--- a/docs/operate/modules/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Modules"
-weight: 110
-layout: "empty"
-type: "docs"
-empty_node: true
-open_on_desktop: true
-header_only: true
-canonical: "/operate/install/setup/"
----
diff --git a/docs/operate/modules/advanced/_index.md b/docs/operate/modules/advanced/_index.md
deleted file mode 100644
index 62fd81e99f..0000000000
--- a/docs/operate/modules/advanced/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Advanced"
-weight: 300
-layout: "empty"
-type: "docs"
-empty_node: true
-open_on_desktop: true
-description: "Advanced information on modules."
-canonical: "/operate/modules/advanced/platform-apis/"
----
diff --git a/docs/operate/modules/advanced/cpp-module.md b/docs/operate/modules/advanced/cpp-module.md
deleted file mode 100644
index 2690a380f4..0000000000
--- a/docs/operate/modules/advanced/cpp-module.md
+++ /dev/null
@@ -1,1688 +0,0 @@
----
-title: "Create a new module with C++"
-linkTitle: "Create a C++ module"
-type: "docs"
-weight: 25
-images: ["/registry/module-puzzle-piece.svg"]
-tags: ["modular resources", "components", "services", "registry"]
-description: "Add support for a new component or service model by writing a module in C++."
-languages: ["c++"]
-viamresources: []
-platformarea: ["registry"]
-level: "Intermediate"
-date: "2024-07-30"
-# updated: ""  # When the tutorial was last entirely checked
-cost: "0"
-draft: true # Take out Go and Python, and check updatedness before un-drafting.
-aliases:
-  - /operate/modules/other-hardware/cpp-module/
----
-
-Viam provides built-in support for a variety of different {{< glossary_tooltip term_id="component" text="components" >}} and {{< glossary_tooltip term_id="service" text="services" >}}, as well as a registry full of {{< glossary_tooltip term_id="module" text="modules" >}} created by other users.
-If no [existing modules](/operate/modules/configure-modules/) support your specific use case, you can write your own custom modular {{< glossary_tooltip term_id="resource" text="resources" >}} by creating a module, and either upload it to the [registry](https://app.viam.com/registry) to share it publicly, or deploy it to your machine as a local module without uploading it to the registry.
-
-Follow the instructions below to learn how to write a new module using your preferred language and its corresponding [Viam SDK](/reference/sdks/), and then deploy it to your machines.
-
-{{< alert title="Note: viam-micro-server modules" color="note" >}}
-[`viam-micro-server`](/operate/reference/viam-micro-server/) works differently from the RDK (and `viam-server`), so creating modular resources for it is different from the process described on this page.
-Refer to the [Micro-RDK Module Template on GitHub](https://github.com/viamrobotics/micro-rdk/tree/main/templates/module) for information on how to create custom resources for your `viam-micro-server` machine.
-You will need to [recompile and flash your ESP32 yourself](/operate/install/setup/) instead of using Viam's prebuilt binary and installer.
-{{< /alert >}}
-
-{{% alert title="Tip" color="tip" %}}
-For a simplified step-by-step guide, see [Create a Hello World module](/operate/modules/write-a-driver-module/hello-world-module/).
-{{% /alert %}}
-
-You can also watch this guide to creating a vision service module:
-
-{{<youtube embed_url="https://www.youtube-nocookie.com/embed/Yz6E07To9Mc">}}
-
-## Write a module
-
-Generally, to write a module, you will complete the following steps:
-
-1. Choose a Viam API to implement in your model.
-1. Write your new model definition code to map all the capabilities of your model to the API.
-1. Write an entry point (main program) file that registers your model with the Viam SDK and starts it up.
-1. Compile or package the model definition file or files, main program file, and any supporting files into a single executable file (a module) that can be run by `viam-server`.
-
-While you can certainly combine the resource model definition and the main program code into a single file if desired (for example, a single `main.py` program that includes both the model definition and the `main()` program that uses it), this guide will use separate files for each.
-
-### Choose an API to implement in your model
-
-Look through the [component APIs](/reference/apis/#component-apis) and [service API](/reference/apis/#service-apis) and find the API that best fits your use case.
-Each API contains various methods which you will need to define in your module:
-
-- One or more methods specific to that API, such as the servo component's `Move` and `GetPosition` methods.
-- Inherited `ResourceBase` methods such as `DoCommand` and `Close`, common to all Viam {{< glossary_tooltip term_id="resource" text="resource" >}} APIs.
-- (For some APIs) Other inherited methods, for example all actuator APIs such as the motor API and servo API inherit `IsMoving` and `Stop`.
-
-{{< expand "Click for more guidance" >}}
-Think about what functionality you want your module to provide, what methods you need, and choose an API to implement accordingly.
-For example, the [sensor API](/reference/apis/components/sensor/) has a `GetReadings` method, so if you create a module for a model of sensor, you'll need to write code to provide a response to the `GetReadings` method.
-If instead of just getting readings, you actually have an encoder and need to be able to reset the zero position, use the [encoder API](/reference/apis/components/encoder/) so you can define functionality behind the `GetPosition` and `ResetPosition` methods.
-
-In addition to the list of methods, another reason to choose one API over another is how certain APIs fit into the Viam ecosystem.
-For example, though you could technically implement a GPS as a sensor with just the `GetReadings` method, if you implement it as a movement sensor then you have access to methods like `GetCompassHeading` which allow you to use your GPS module with the [navigation service](/operate/reference/services/navigation/).
-For this reason, it's generally best to choose the API that most closely matches your hardware or software.
-{{< /expand >}}
-
-{{% alert title=Note color="note" %}}
-If you want to write a module to add support to a new type of component or service that is relatively unique, consider using the generic API for your resource type to build your own API:
-
-- If you are working with a component that doesn't fit into any of the existing component APIs, you can use the [generic component](/operate/reference/components/generic/) to build your own component API.
-- If you are designing a service that doesn't fit into any of the existing service APIs, you can use the [generic service](/operate/reference/components/generic/) to build your own service API.
-- It is also possible to [define an entirely new API](/operate/reference/advanced-modules/create-subtype/), but this is even more advanced than using `generic`.
-
-Most module use cases, however, benefit from implementing an existing API instead of `generic`.
-{{% /alert %}}
-
-#### Valid API identifiers
-
-Each existing component or service API has a unique identifier in the form of a colon-delimited triplet.
-You will use this {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet" >}} when creating your new model, to indicate which API it uses.
-
-The API namespace triplet is the same for all built-in and modular models that implement a given API.
-For example, every model of motor built into Viam, as well as every custom model of motor provided by a module, all use the same API namespace triplet `rdk:component:motor` to indicate that they implement the [motor API](/operate/reference/components/motor/#api).
-
-The three pieces of the API namespace triplet are as follows:
-
-{{< tabs >}}
-{{% tab name="Component" %}}
-
-- `namespace`: `rdk`
-- `type`: `component`
-- `subtype`: any one of [these component proto files](https://github.com/viamrobotics/api/tree/main/proto/viam/component), for example `motor` if you are creating a new model of motor
-
-{{% /tab %}}
-{{% tab name="Service" %}}
-
-- `namespace`: `rdk`
-- `type`: `service`
-- `subtype`: any one of [these service proto files](https://github.com/viamrobotics/api/tree/main/proto/viam/service), for example `vision` if you are creating a new model of vision service
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Name your new resource model
-
-In addition to determining which existing API namespace triplet to use when creating your module, you need to decide on a separate triplet unique to your model.
-
-{{< expand "API namespace triplet and model namespace triplet example" >}}
-
-The `rand:yahboom:arm` model and the `rand:yahboom:gripper` model use the module name (and matching repo name) [yahboom](https://github.com/viam-labs/yahboom).
-The models implement the `rdk:component:arm` and the `rdk:component:gripper` API to support the Yahboom DOFBOT arm and gripper, respectively:
-
-```json
-{
-    "api": "rdk:component:arm",
-    "model": "rand:yahboom:arm"
-},
-{
-    "api": "rdk:component:gripper",
-    "model": "rand:yahboom:gripper"
-}
-```
-
-{{< /expand >}}
-
-A resource model is identified by a unique name, called the {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet" >}}, using the format: `namespace:module-name:model-name`, where:
-
-- `namespace` is the [namespace of your organization](/operate/modules/advanced/metajson/#create-a-namespace-for-your-organization).
-  - For example, if your organization uses the `acme` namespace, your models must all begin with `acme`, like `acme:module-name:mybase`.
-    If you do not intend to [upload your module](#upload-your-module-to-the-modular-resource-registry) to the [registry](https://app.viam.com/registry), you do not need to use your organization's namespace as your model's namespace.
-  - The `viam` namespace is reserved for models provided by Viam.
-- `module-name` is the name of your module.
-  Your `module-name` should describe the common functionality provided across the model or models provided by that module.
-  - Many people also choose to use the module name as the name of the code repository (GitHub repo) that houses the module code.
-- `model-name` is the name of the new resource model that your module will provide.
-
-For example, if your organization namespace is `acme`, and you have written a new base implementation named `mybase` which you have supported with a module named `my-custom-base-module`, you would use the namespace `acme:my-custom-base-module:mybase` for your model.
-
-More requirements:
-
-- Your model triplet must be all-lowercase.
-- Your model triplet may only use alphanumeric (`a-z` and `0-9`), hyphen (`-`), and underscore (`_`) characters.
-
-Determine the model name you want to use based on these requirements, then proceed to the next section.
-
-### Write your new resource model definition
-
-In this step, you will code the logic that is unique to your model.
-
-{{% alert title="Tip (optional)" color="tip" %}}
-
-If you are using Golang, use the [Golang Module templates](https://github.com/viam-labs/module-templates-golang) which contain detailed instructions for creating your module.
-
-If you are using Python, you can use the [Viam module generator](https://github.com/viam-labs/generator-viam-module/) to generate the scaffolding for a module with one resource model.
-
-{{% /alert %}}
-
-{{< expand "Additional example modules" >}}
-
-Browse additional example modules by language:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-<!-- prettier-ignore -->
-| Module | Repository | Description |
-| ------ | ---------- | ----------- |
-| [berryimu](https://app.viam.com/module/viam-labs/berryimu) | [viam-labs/berry-imu](https://github.com/viam-labs/berry-imu) | Extends the built-in [movement sensor API](/reference/apis/components/movement-sensor/) to support using the BerryIMU v3 accelerometer, gyroscope and magnetometer using an I2C connection on ARM64 systems. |
-| [oak](https://app.viam.com/module/viam/oak) | [viam-modules/viam-camera-oak](https://github.com/viam-modules/viam-camera-oak) | Extends the built-in [camera API](/reference/apis/components/camera/) to support OAK cameras. |
-| [odrive](https://app.viam.com/module/viam/odrive) | [viamrobotics/odrive](https://github.com/viamrobotics/odrive) | Extends the built-in [motor API](/operate/reference/components/motor/#api) to support the ODrive motor. This module provides two models, one for a `canbus`-connected ODrive motor, and one for a `serial`-connected ODrive motor. |
-| [yahboom](https://app.viam.com/module/rand/yahboom) | [viamlabs/yahboom](https://github.com/viam-labs/yahboom) | Extends the built-in [arm API](/reference/apis/components/arm/) and [gripper API](/reference/apis/components/gripper/) to support the Yahboom Dofbot robotic arm. |
-
-For more Python module examples:
-
-- See the [Python SDK `examples` directory](https://github.com/viamrobotics/viam-python-sdk/tree/main/examples) for sample module code of varying complexity.
-- For an example featuring a sensor, see [MCP300x](https://github.com/viam-labs/mcp300x-adc-sensor).
-- For additional examples use the [modular resources search](/operate/modules/configure-modules/#for-use-with-64-bit-architecture) to search for examples of the model you are implementing, and click on the model's link to be able to browse its code.
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-<!-- prettier-ignore -->
-| Module | Repository | Description |
-| ------ | ---------- | ----------- |
-| [agilex-limo](https://app.viam.com/module/viam/agilex-limo) | [viamlabs/agilex](https://github.com/viam-labs/agilex/) | Extends the built-in [base API](/reference/apis/components/base/) to support the Agilex Limo base. |
-| [rplidar](https://app.viam.com/module/viam/rplidar) | [viamrobotics/rplidar](https://github.com/viamrobotics/rplidar) | Extends the built-in [camera API](/reference/apis/components/camera/) to support several models of the SLAMTEC RPlidar. |
-| [filtered-camera](https://app.viam.com/module/erh/filtered-camera) | [erh/filtered_camera](https://github.com/erh/filtered_camera) | Extends the built-in [camera API](/reference/apis/components/camera/) to enable filtering captured images by comparing to a defined ML model, and only syncing matching images to Viam. See the [filtered-camera guide](/data-ai/capture-data/filter-before-sync/) for more information. |
-
-For more Go module examples:
-
-- See the [Go SDK `examples` directory](https://github.com/viamrobotics/rdk/blob/main/examples/) for sample module code of varying complexity.
-- For additional examples use the [modular resources search](/operate/modules/configure-modules/#for-use-with-64-bit-architecture) to search for examples of the model you are implementing, and click on the model's link to be able to browse its code.
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-<!-- prettier-ignore -->
-| Module | Repository | Description |
-| ------ | ---------- | ----------- |
-| [csi-cam](https://app.viam.com/module/viam/csi-cam) | [viamrobotics/csi-camera](https://github.com/viamrobotics/csi-camera/) | Extends the built-in [camera API](/reference/apis/components/camera/) to support the Intel CSI camera. |
-<!-- | [module-example-cpp](https://app.viam.com/module/viam/module-example-cpp) | [viamrobotics/module-example-cpp](https://github.com/viamrobotics/module-example-cpp) | Extends the built-in [sensor API](/operate/reference/components/sensor/#api) to report wifi statistics. | -->
-
-{{% /tab %}}
-{{% /tabs %}}
-
-Explore the full list of available modules in the [registry](https://app.viam.com/registry).
-{{< /expand >}}
-
-Follow the instructions below to define the capabilities provided by your model, for the language you are using to write your module code:
-
-{{% alert title="Note: Pin numbers" color="note" %}}
-
-If your module references {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}, you should use physical board pin numbers, _not_ GPIO (BCM) numbers, to maintain consistency across {{< glossary_tooltip term_id="resource" text="resources" >}} from different sources.
-
-{{% /alert %}}
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-First, inspect the built-in class provided by the resource API that you are extending.
-
-For example, if you wanted to add support for a new [base component](/operate/reference/components/base/) to Viam (the component that represents the central physical platform of your machine, to which all other components are connected), you would start by looking at the built-in `Base` component class, which is defined in the [Viam Python SDK](https://github.com/viamrobotics/viam-python-sdk) in the following file:
-
-<!-- prettier-ignore -->
-| Resource Model File | Description |
-| ------------------- | ----------- |
-| [src/viam/components/base/base.py](https://github.com/viamrobotics/viam-python-sdk/blob/main/src/viam/components/base/base.py) | Defines the built-in `Base` class, which includes several built-in methods such as `move_straight()`. |
-
-{{% alert title="Tip" color="tip" %}}
-You can view the other built-in component classes in similar fashion.
-For example, the `Camera` class is defined in [camera.py](https://github.com/viamrobotics/viam-python-sdk/blob/main/src/viam/components/camera/camera.py) and the `Sensor` class is defined in [sensor.py](https://github.com/viamrobotics/viam-python-sdk/blob/main/src/viam/components/sensor/sensor.py).
-The same applies to service APIs.
-For example, the `MLModel` class for the ML Model service is defined in [mlmodel.py](https://github.com/viamrobotics/viam-python-sdk/blob/main/src/viam/services/mlmodel/mlmodel.py).
-{{% /alert %}}
-
-Take note of the methods defined as part of the class API, such as `move_straight()` for the `Base` class.
-Your new resource model must either:
-
-- implement all of the methods that the corresponding resource API provides, or
-- explicitly raise a `NotImplementedError()` in the body of functions you do not want to implement or put `pass`.
-
-Otherwise, your new class will not instantiate.
-
-Next, create a file that will define your new resource model.
-This file will inherit from the existing class for your resource type, implement each built-in method for that class (or raise a `NotImplementedError()` for it), and define any new functionality you want to include as part of your model.
-
-For example, the following file, `my_base.py`:
-
-- defines a new model `acme:my-custom-base-module:mybase` by implementing a new `MyBase` class, which inherits from the built-in class `Base`.
-- defines a new constructor `new_base()` and a new method `validate_config()`.
-- does not implement several built-in methods, including `get_properties()` and `set_velocity()`, but instead raises a `NotImplementedError` error in the body of those functions.
-  This prevents these methods from being used by new base components that use this modular resource, but meets the requirement that all built-in methods either be defined or raise a `NotImplementedError()` error, to ensure that the new `MyBase` class successfully instantiates.
-
-{{< expand "Click to view sample code for my_base.py" >}}
-
-```python {class="line-numbers linkable-line-numbers"}
-from typing import ClassVar, Mapping, Sequence, Any, Dict, Optional, cast
-
-from typing_extensions import Self
-
-from viam.components.base import Base
-from viam.components.motor import Motor
-from viam.module.types import Reconfigurable
-from viam.module.module import Module
-from viam.proto.app.robot import ComponentConfig
-from viam.proto.common import ResourceName, Vector3
-from viam.resource.base import ResourceBase
-from viam.resource.registry import Registry, ResourceCreatorRegistration
-from viam.resource.types import Model, ModelFamily
-from viam.utils import ValueTypes
-from viam.logging import getLogger
-
-LOGGER = getLogger(__name__)
-
-
-class MyBase(Base, Reconfigurable):
-    """
-    MyBase implements a base that only supports set_power
-    (basic forward/back/turn controls) is_moving (check if in motion), and stop
-    (stop all motion).
-
-    It inherits from the built-in resource API Base and conforms to the
-    ``Reconfigurable`` protocol, which signifies that this component can be
-    reconfigured. Additionally, it specifies a constructor function
-    ``MyBase.new_base`` which confirms to the
-    ``resource.types.ResourceCreator`` type required for all models.
-    """
-
-    # Here is where we define our new model's colon-delimited-triplet:
-    # acme:my-custom-base-module:mybase
-    # acme = namespace, my-custom-base-module = module-name,
-    # mybase = model name
-    MODEL: ClassVar[Model] = Model(
-        ModelFamily("acme", "my-custom-base-module"), "mybase")
-
-    def __init__(self, name: str, left: str, right: str):
-        super().__init__(name, left, right)
-
-    # Constructor
-    @classmethod
-    def new_base(cls,
-                 config: ComponentConfig,
-                 dependencies: Mapping[ResourceName, ResourceBase]) -> Self:
-        base = cls(config.name)
-        base.reconfigure(config, dependencies)
-        return base
-
-    # Validates JSON Configuration
-    @classmethod
-    def validate_config(cls, config: ComponentConfig) -> Sequence[str]:
-        left_name = config.attributes.fields["motorL"].string_value
-        if left_name == "":
-            raise Exception(
-                "A motorL attribute is required for a MyBase component.")
-        right_name = [config.attributes.fields["motorR"].string_value]
-        if right_name == "":
-            raise Exception(
-                "A motorR attribute is required for a MyBase component.")
-        return [left_name, right_name]
-
-    # Handles attribute reconfiguration
-    def reconfigure(self,
-                    config: ComponentConfig,
-                    dependencies: Mapping[ResourceName, ResourceBase]):
-        left_name = config.attributes.fields["motorL"].string_value
-        right_name = config.attributes.fields["motorR"].string_value
-
-        left_motor = dependencies[Motor.get_resource_name(left_name)]
-        right_motor = dependencies[Motor.get_resource_name(right_name)]
-
-        self.left = cast(Motor, left_motor)
-        self.right = cast(Motor, right_motor)
-
-    """
-    Implement the methods the Viam RDK defines for the base API
-    (rdk:component:base)
-    """
-
-    # move_straight: unimplemented
-    async def move_straight(self,
-                            distance: int,
-                            velocity: float,
-                            *,
-                            extra: Optional[Dict[str, Any]] = None,
-                            timeout: Optional[float] = None,
-                            **kwargs):
-        raise NotImplementedError
-
-    # spin: unimplemented
-    async def spin(self,
-                   angle: float,
-                   velocity: float,
-                   *,
-                   extra: Optional[Dict[str, Any]] = None,
-                   timeout: Optional[float] = None,
-                   **kwargs):
-        raise NotImplementedError
-
-    # set_power: set the linear and angular velocity of the left and right
-    # motors on the base
-    async def set_power(self,
-                        linear: Vector3,
-                        angular: Vector3,
-                        *,
-                        extra: Optional[Dict[str, Any]] = None,
-                        timeout: Optional[float] = None,
-                        **kwargs):
-
-        # stop the base if absolute value of linear and angular velocity is
-        # less than .01
-        if abs(linear.y) < 0.01 and abs(angular.z) < 0.01:
-            return self.stop(extra=extra, timeout=timeout)
-
-        # use linear and angular velocity to calculate percentage of max power
-        # to pass to SetPower for left & right motors
-        sum = abs(linear.y) + abs(angular.z)
-
-        self.left.set_power(power=((linear.y - angular.z) / sum),
-                            extra=extra,
-                            timeout=timeout)
-        self.right.set_power(power=((linear.y + angular.z) / sum),
-                             extra=extra,
-                             timeout=timeout)
-
-    # set_velocity: unimplemented
-    async def set_velocity(self,
-                           linear: Vector3,
-                           angular: Vector3,
-                           *,
-                           extra: Optional[Dict[str, Any]] = None,
-                           timeout: Optional[float] = None,
-                           **kwargs):
-        raise NotImplementedError
-
-    # get_properties: unimplemented
-    async def get_properties(self,
-                             extra: Optional[Dict[str, Any]] = None,
-                             timeout: Optional[float] = None,
-                             **kwargs):
-        raise NotImplementedError
-
-    # stop: stop the base from moving by stopping both motors
-    async def stop(self,
-                   *,
-                   extra: Optional[Dict[str, Any]] = None,
-                   timeout: Optional[float] = None,
-                   **kwargs):
-        self.left.stop(extra=extra, timeout=timeout)
-        self.right.stop(extra=extra, timeout=timeout)
-
-    # is_moving: check if either motor on the base is moving with motors'
-    # is_powered
-    async def is_moving(self,
-                        *,
-                        extra: Optional[Dict[str, Any]] = None,
-                        timeout: Optional[float] = None,
-                        **kwargs) -> bool:
-        return self.left.is_powered(extra=extra, timeout=timeout)[0] or \
-            self.right.is_powered(extra=extra, timeout=timeout)[0]
-```
-
-{{< /expand >}}
-
-When implementing built-in methods from the Viam Python SDK in your model, be sure your implementation of those methods returns any values designated in the built-in function's return signature, typed correctly.
-For example, the `is_moving()` implementation in the example code above returns a `bool` value, which matches the return value of the built-in `is_moving()` function as defined in the Viam Python SDK in the file [`base.py`](https://github.com/viamrobotics/viam-python-sdk/blob/main/src/viam/components/base/base.py).
-
-For more information on the base component API methods used in this example, see the following resources:
-
-- [Python SDK documentation for the `Base` class](https://python.viam.dev/autoapi/viam/components/base/index.html)
-- [Base API methods](/reference/apis/components/base/)
-
-{{% /tab %}}
-{{% tab name="Go"%}}
-
-First, inspect the built-in package provided by the resource API that you are extending.
-
-For example, if you wanted to add support for a new [base component](/operate/reference/components/base/) to Viam (the component that represents the central physical platform of your machine, to which all other components are connected), you would start by looking at the built-in `base` component package, which is defined in the [Viam Go SDK](https://github.com/viamrobotics/rdk/) in the following file:
-
-<!-- prettier-ignore -->
-| Resource Model File | Description |
-| ------------------- | ----------- |
-| [components/base/base.go](https://github.com/viamrobotics/rdk/blob/main/components/base/base.go) | Defines the built-in `base` package, which includes several built-in methods such as `MoveStraight()`. |
-
-{{% alert title="Tip" color="tip" %}}
-You can view the other built-in component packages in similar fashion.
-For example, the `camera` package is defined in [camera.go](https://github.com/viamrobotics/rdk/blob/main/components/camera/camera.go) and the `sensor` package is defined in [sensor.go](https://github.com/viamrobotics/rdk/blob/main/components/sensor/sensor.go).
-The same applies to service APIs.
-For example, the `mlmodel` package for the ML Model service is defined in [mlmodel.go](https://github.com/viamrobotics/rdk/blob/main/services/mlmodel/mlmodel.go).
-{{% /alert %}}
-
-Take note of the methods defined as part of the package API, such as `MoveStraight()` for the `base` package.
-Your new resource model must either:
-
-- implement all of the methods that the corresponding resource API provides, or
-- explicitly return an `errUnimplemented` error in the body of functions you do not want to implement.
-
-Otherwise, your new package will not instantiate.
-
-Next, create a file that will define your new resource model.
-This file will inherit from the existing package for your resource type, implement - or return an `errUnimplemented` error for - each built-in method for that package, and define any new functionality you want to include as part of your model.
-
-For example, the following file, `mybase.go`:
-
-- defines a new model `acme:my-custom-base-module:mybase` by implementing a new `mybase` package, which inherits from the built-in package `base`.
-- defines a new constructor `newBase()` and a new method `Validate()`.
-- does not implement several built-in methods, including `MoveStraight()` and `SetVelocity()`, but instead returns an `errUnimplemented` error in the body of those methods.
-  This prevents these methods from being used by new base components that use this modular resource, but meets the requirement that all built-in methods either be defined or return an `errUnimplemented` error, to ensure that the new `mybase` package successfully instantiates.
-
-{{< expand "Click to view sample code for mybase.go" >}}
-
-```go {class="line-numbers linkable-line-numbers"}
-// Package mybase implements a base that only supports SetPower (basic forward/back/turn controls), IsMoving (check if in motion), and Stop (stop all motion).
-// It extends the built-in resource API Base and implements methods to handle resource construction, attribute configuration, and reconfiguration.
-
-package mybase
-
-import (
-    "context"
-    "fmt"
-    "math"
-
-    "github.com/golang/geo/r3"
-    "github.com/pkg/errors"
-    "go.uber.org/multierr"
-
-    "go.viam.com/rdk/components/base"
-    "go.viam.com/rdk/components/base/kinematicbase"
-    "go.viam.com/rdk/components/motor"
-    "go.viam.com/rdk/logging"
-    "go.viam.com/rdk/resource"
-    "go.viam.com/rdk/spatialmath"
-)
-
-// Here is where we define your new model's colon-delimited-triplet (acme:my-custom-base-module:mybase)
-// acme = namespace, my-custom-base-module = module-name, mybase = model name.
-var (
-    Model            = resource.NewModel("acme", "my-custom-base-module", "mybase")
-    errUnimplemented = errors.New("unimplemented")
-)
-
-const (
-    myBaseWidthMm        = 500.0 // Base has a wheel tread of 500 millimeters
-    myBaseTurningRadiusM = 0.3   // Base turns around a circle of radius .3 meters
-)
-
-func init() {
-    resource.RegisterComponent(base.API, Model, resource.Registration[base.Base, *Config]{
-        Constructor: newBase,
-    })
-}
-
-func newBase(ctx context.Context, deps resource.Dependencies, conf resource.Config, logger logging.Logger) (base.Base, error) {
-    b := &myBase{
-        Named:  conf.ResourceName().AsNamed(),
-        logger: logger,
-    }
-    if err := b.Reconfigure(ctx, deps, conf); err != nil {
-        return nil, err
-    }
-    return b, nil
-}
-
-
-// Reconfigure reconfigures with new settings.
-func (b *myBase) Reconfigure(ctx context.Context, deps resource.Dependencies, conf resource.Config) error {
-    b.left = nil
-    b.right = nil
-
-    // This takes the generic resource.Config passed down from the parent and converts it to the
-    // model-specific (aka "native") Config structure defined, above making it easier to directly access attributes.
-    baseConfig, err := resource.NativeConfig[*Config](conf)
-    if err != nil {
-        return err
-    }
-
-    b.left, err = motor.FromDependencies(deps, baseConfig.LeftMotor)
-    if err != nil {
-        return errors.Wrapf(err, "unable to get motor %v for mybase", baseConfig.LeftMotor)
-    }
-
-    b.right, err = motor.FromDependencies(deps, baseConfig.RightMotor)
-    if err != nil {
-        return errors.Wrapf(err, "unable to get motor %v for mybase", baseConfig.RightMotor)
-    }
-
-    geometries, err := kinematicbase.CollisionGeometry(conf.Frame)
-    if err != nil {
-        b.logger.CWarnf(ctx, "base %v %s", b.Name(), err.Error())
-    }
-    b.geometries = geometries
-
-    // Stop motors when reconfiguring.
-    return multierr.Combine(b.left.Stop(context.Background(), nil), b.right.Stop(context.Background(), nil))
-}
-
-// DoCommand simply echos whatever was sent.
-func (b *myBase) DoCommand(ctx context.Context, cmd map[string]interface{}) (map[string]interface{}, error) {
-    return cmd, nil
-}
-
-// Config contains two component (motor) names.
-type Config struct {
-    LeftMotor  string `json:"motorL"`
-    RightMotor string `json:"motorR"`
-}
-
-// Validate validates the config and returns implicit dependencies,
-// this Validate checks if the left and right motors exist for the module's base model.
-func (cfg *Config) Validate(path string) ([]string, error) {
-    // check if the attribute fields for the right and left motors are non-empty
-    // this makes them required for the model to successfully build
-    if cfg.LeftMotor == "" {
-        return nil, fmt.Errorf(`expected "motorL" attribute for mybase %q`, path)
-    }
-    if cfg.RightMotor == "" {
-        return nil, fmt.Errorf(`expected "motorR" attribute for mybase %q`, path)
-    }
-
-    // Return the left and right motor names so that `newBase` can access them as dependencies.
-    return []string{cfg.LeftMotor, cfg.RightMotor}, nil
-}
-
-type myBase struct {
-    resource.Named
-    left       motor.Motor
-    right      motor.Motor
-    logger     logging.Logger
-    geometries []spatialmath.Geometry
-}
-
-// MoveStraight does nothing.
-func (b *myBase) MoveStraight(ctx context.Context, distanceMm int, mmPerSec float64, extra map[string]interface{}) error {
-    return errUnimplemented
-}
-
-// Spin does nothing.
-func (b *myBase) Spin(ctx context.Context, angleDeg, degsPerSec float64, extra map[string]interface{}) error {
-    return errUnimplemented
-}
-
-// SetVelocity does nothing.
-func (b *myBase) SetVelocity(ctx context.Context, linear, angular r3.Vector, extra map[string]interface{}) error {
-    return errUnimplemented
-}
-
-// SetPower computes relative power between the wheels and sets power for both motors.
-func (b *myBase) SetPower(ctx context.Context, linear, angular r3.Vector, extra map[string]interface{}) error {
-    b.logger.CDebugf(ctx, "SetPower Linear: %.2f Angular: %.2f", linear.Y, angular.Z)
-    if math.Abs(linear.Y) < 0.01 && math.Abs(angular.Z) < 0.01 {
-        return b.Stop(ctx, extra)
-    }
-    sum := math.Abs(linear.Y) + math.Abs(angular.Z)
-    err1 := b.left.SetPower(ctx, (linear.Y-angular.Z)/sum, extra)
-    err2 := b.right.SetPower(ctx, (linear.Y+angular.Z)/sum, extra)
-    return multierr.Combine(err1, err2)
-}
-
-// Stop halts motion.
-func (b *myBase) Stop(ctx context.Context, extra map[string]interface{}) error {
-    b.logger.CDebug(ctx, "Stop")
-    err1 := b.left.Stop(ctx, extra)
-    err2 := b.right.Stop(ctx, extra)
-    return multierr.Combine(err1, err2)
-}
-
-// IsMoving returns true if either motor is active.
-func (b *myBase) IsMoving(ctx context.Context) (bool, error) {
-    for _, m := range []motor.Motor{b.left, b.right} {
-        isMoving, _, err := m.IsPowered(ctx, nil)
-        if err != nil {
-            return false, err
-        }
-        if isMoving {
-            return true, err
-        }
-    }
-    return false, nil
-}
-
-// Properties returns details about the physics of the base.
-func (b *myBase) Properties(ctx context.Context, extra map[string]interface{}) (base.Properties, error) {
-    return base.Properties{
-        TurningRadiusMeters: myBaseTurningRadiusM,
-        WidthMeters:         myBaseWidthMm * 0.001, // converting millimeters to meters
-    }, nil
-}
-
-// Geometries returns physical dimensions.
-func (b *myBase) Geometries(ctx context.Context, extra map[string]interface{}) ([]spatialmath.Geometry, error) {
-    return b.geometries, nil
-}
-
-// Close stops motion during shutdown.
-func (b *myBase) Close(ctx context.Context) error {
-    return b.Stop(ctx, nil)
-}
-```
-
-{{< /expand >}}
-
-{{< alert title="Note" color="note" >}}
-For an example featuring a sensor, see [MCP3004-8](https://github.com/mestcihazal/mcp3004-8-go).
-
-For additional examples use the [modular resources search](/operate/modules/configure-modules/#for-use-with-64-bit-architecture) to search for examples of the model you are implementing, and click on the model's link to be able to browse its code.
-{{< /alert >}}
-
-When implementing built-in methods from the Viam Go SDK in your model, be sure your implementation of those methods returns any values designated in the built-in method's return signature, typed correctly.
-For example, the `SetPower()` implementation in the example code above returns a `multierr` value (as provided by the [`multierr` package](https://pkg.go.dev/go.uber.org/multierr)), which allows for transparently combining multiple Go `error` return values together.
-This matches the `error` return type of the built-in `SetPower()` method as defined in the Viam Go SDK in the file [`base.go`](https://github.com/viamrobotics/rdk/blob/main/components/base/base.go).
-
-For more information on the base component API methods used in this example, see the following resources:
-
-- [Go SDK documentation for the `base` package](https://pkg.go.dev/go.viam.com/rdk/components/base#pkg-functions)
-- [Base API methods](/reference/apis/components/base/)
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-First, inspect the built-in class provided by the resource API that you are extending.
-In the C++ SDK, all built-in classes are abstract classes.
-
-For example, if you wanted to add support for a new [base component](/operate/reference/components/base/) to Viam (the component that represents the central physical platform of your machine, to which all other components are connected), you would start by looking at the built-in `Base` component class, which is defined in the [Viam C++ SDK](https://cpp.viam.dev/) in the following files:
-
-<!-- prettier-ignore -->
-| Resource Model File | Description |
-| ------------------- | ----------- |
-| [components/base/base.hpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/base.hpp) | Defines the API of the built-in `Base` class, which includes the declaration of several purely virtual built-in functions such as `move_straight()`. |
-| [components/base/base.cpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/base.cpp) | Provides implementations of the non-purely virtual functionality defined in `base.hpp`. |
-
-{{% alert title="Tip" color="tip" %}}
-You can view the other built-in component classes in similar fashion.
-For example, the API of the built-in `Camera` class is defined in [camera.hpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/camera.hpp) and its non-purely virtual functions are declared in [camera.cpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/camera.cpp), while the API of the built-in `Sensor` class is defined in [sensor.hpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/sensor.hpp) and its non-purely virtual functions are declared in [sensor.cpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/sensor.cpp).
-The same applies to service APIs.
-For example, the API of the built-in `MLModelService` class for the ML Model service is defined in [mlmodel.hpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/services/mlmodel.hpp) and its non-purely virtual functions declared in [mlmodel.cpp](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/services/mlmodel.cpp).
-{{% /alert %}}
-
-Take note of the functions defined as part of the class API, such as `move_straight()` for the `Base` class.
-Your new resource model must either:
-
-- define all _pure virtual methods_ that the corresponding resource API provides, or
-- explicitly `throw` a `runtime_error` in the body of functions you do not want to implement.
-
-Otherwise, your new class will not instantiate.
-For example, if your model implements the `base` class, you would either need to implement the [`move_straight()` virtual method](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/base.hpp#L72), or `throw` a `runtime_error` in the body of that function.
-However, you would _not_ need to implement the [`resource_registration()`](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/base.hpp#L56) function, as it is not a virtual method.
-
-Next, create your header file (`.hpp`) and source file (`.cpp`), which together define your new resource model.
-The header file defines the API of your class, and includes the declaration of any purely virtual functions, while the source file includes implementations of the functionality of your class.
-
-For example, the files below define the new `MyBase` class and its constituent functions:
-
-- The `my_base.hpp` header file defines the API of the `MyBase` class, which inherits from the built-in `Base` class.
-  It defines a new method `validate()`, but does not implement several built-in functions, including `move_straight()` and `set_velocity()`, instead it raises a `runtime_error` in the body of those functions.
-  This prevents these functions from being used by new base components that use this modular resource, but meets the requirement that all built-in functions either be defined or `throw` a `runtime_error` error, to ensure that the new `MyBase` class successfully instantiates.
-- The `my_base.cpp` source file contains the function and object definitions used by the `MyBase` class.
-
-Note that the model triplet itself, `acme:my-custom-base-module:mybase` in this example, is defined in the entry point (main program) file `main.cpp`, which is described in the next section.
-
-{{< expand "Click to view sample code for the my_base.hpp header file" >}}
-
-```cpp {class="line-numbers linkable-line-numbers"}
-#pragma once
-
-#include <viam/sdk/components/base/base.hpp>
-#include <viam/sdk/components/component.hpp>
-#include <viam/sdk/components/motor/motor.hpp>
-#include <viam/sdk/config/resource.hpp>
-#include <viam/sdk/resource/resource.hpp>
-
-using namespace viam::sdk;
-
-// `MyBase` inherits from the `Base` class defined in the Viam C++ SDK and
-// implements some of the relevant methods along with `reconfigure`. It also
-// specifies a static `validate` method that checks configuration validity.
-class MyBase : public Base {
-   public:
-    MyBase(Dependencies deps, ResourceConfig cfg) : Base(cfg.name()) {
-        this->reconfigure(deps, cfg);
-    };
-    void reconfigure(Dependencies deps, ResourceConfig cfg) override;
-    static std::vector<std::string> validate(ResourceConfig cfg);
-
-    bool is_moving() override;
-    void stop(const AttributeMap& extra) override;
-    void set_power(const Vector3& linear,
-                   const Vector3& angular,
-                   const AttributeMap& extra) override;
-
-    AttributeMap do_command(const AttributeMap& command) override;
-    std::vector<GeometryConfig> get_geometries(const AttributeMap& extra) override;
-    Base::properties get_properties(const AttributeMap& extra) override;
-
-    void move_straight(int64_t distance_mm, double mm_per_sec, const AttributeMap& extra) override {
-        throw std::runtime_error("move_straight unimplemented");
-    }
-    void spin(double angle_deg, double degs_per_sec, const AttributeMap& extra) override {
-        throw std::runtime_error("spin unimplemented");
-    }
-    void set_velocity(const Vector3& linear,
-                      const Vector3& angular,
-                      const AttributeMap& extra) override {
-        throw std::runtime_error("set_velocity unimplemented");
-    }
-
-   private:
-    std::shared_ptr<Motor> left_;
-    std::shared_ptr<Motor> right_;
-};
-```
-
-{{< /expand >}}
-
-{{< expand "Click to view sample code for the my_base.cpp source file" >}}
-
-```cpp {class="line-numbers linkable-line-numbers"}
-#include "my_base.hpp"
-
-#include <exception>
-#include <fstream>
-#include <iostream>
-#include <sstream>
-
-#include <grpcpp/support/status.h>
-
-#include <viam/sdk/components/base/base.hpp>
-#include <viam/sdk/components/component.hpp>
-#include <viam/sdk/config/resource.hpp>
-#include <viam/sdk/resource/resource.hpp>
-
-using namespace viam::sdk;
-
-std::string find_motor(ResourceConfig cfg, std::string motor_name) {
-    auto base_name = cfg.name();
-    auto motor = cfg.attributes()->find(motor_name);
-    if (motor == cfg.attributes()->end()) {
-        std::ostringstream buffer;
-        buffer << base_name << ": Required parameter `" << motor_name
-               << "` not found in configuration";
-        throw std::invalid_argument(buffer.str());
-    }
-    const auto* const motor_string = motor->second->get<std::string>();
-    if (!motor_string || motor_string->empty()) {
-        std::ostringstream buffer;
-        buffer << base_name << ": Required non-empty string parameter `" << motor_name
-               << "` is either not a string "
-                  "or is an empty string";
-        throw std::invalid_argument(buffer.str());
-    }
-    return *motor_string;
-}
-
-void MyBase::reconfigure(Dependencies deps, ResourceConfig cfg) {
-    // Downcast `left` and `right` dependencies to motors.
-    auto left = find_motor(cfg, "left");
-    auto right = find_motor(cfg, "right");
-    for (const auto& kv : deps) {
-        if (kv.first.short_name() == left) {
-            left_ = std::dynamic_pointer_cast<Motor>(kv.second);
-        }
-        if (kv.first.short_name() == right) {
-            right_ = std::dynamic_pointer_cast<Motor>(kv.second);
-        }
-    }
-}
-
-std::vector<std::string> MyBase::validate(ResourceConfig cfg) {
-    // Custom validation can be done by specifying a validate function at the
-    // time of resource registration (see main.cpp) like this one.
-    // Validate functions can `throw` exceptions that will be returned to the
-    // parent through gRPC. Validate functions can also return a vector of
-    // strings representing the implicit dependencies of the resource.
-    //
-    // Here, we return the names of the "left" and "right" motors as found in
-    // the attributes as implicit dependencies of the base.
-    return {find_motor(cfg, "left"), find_motor(cfg, "right")};
-}
-
-bool MyBase::is_moving() {
-    return left_->is_moving() || right_->is_moving();
-}
-
-void MyBase::stop(const AttributeMap& extra) {
-    std::string err_message;
-    bool throw_err = false;
-
-    // make sure we try to stop both motors, even if the first fails.
-    try {
-        left_->stop(extra);
-    } catch (const std::exception& err) {
-        throw_err = true;
-        err_message = err.what();
-    }
-
-    try {
-        right_->stop(extra);
-    } catch (const std::exception& err) {
-        throw_err = true;
-        err_message = err.what();
-    }
-
-    // if we received an err from either motor, throw it.
-    if (throw_err) {
-        throw std::runtime_error(err_message);
-    }
-}
-
-void MyBase::set_power(const Vector3& linear, const Vector3& angular, const AttributeMap& extra) {
-    // Stop the base if absolute value of linear and angular velocity is less
-    // than 0.01.
-    if (abs(linear.y()) < 0.01 && abs(angular.z()) < 0.01) {
-        stop(extra);  // ignore returned status code from stop
-        return;
-    }
-
-    // Use linear and angular velocity to calculate percentage of max power to
-    // pass to set_power for left & right motors
-    auto sum = abs(linear.y()) + abs(angular.z());
-    left_->set_power(((linear.y() - angular.z()) / sum), extra);
-    right_->set_power(((linear.y() + angular.z()) / sum), extra);
-}
-
-AttributeMap MyBase::do_command(const AttributeMap& command) {
-    std::cout << "Received DoCommand request for MyBase " << Resource::name() << std::endl;
-    return command;
-}
-
-std::vector<GeometryConfig> MyBase::get_geometries(const AttributeMap& extra) {
-    auto left_geometries = left_->get_geometries(extra);
-    auto right_geometries = right_->get_geometries(extra);
-    std::vector<GeometryConfig> geometries(left_geometries);
-    geometries.insert(geometries.end(), right_geometries.begin(), right_geometries.end());
-    return geometries;
-}
-
-Base::properties MyBase::get_properties(const AttributeMap& extra) {
-    // Return fake properties.
-    return {2, 4, 8};
-}
-```
-
-{{< /expand >}}
-
-When implementing built-in functions from the Viam C++ SDK in your model, be sure your implementation of those functions returns any values designated in the built-in function's return signature, typed correctly.
-For example, the `set_power()` implementation in the example code above returns three values of type `Vector3`, `Vector3`, `AttributeMap`, which matches the return values of the built-in `set_power()` function as defined in the Viam C++ SDK in the file [`base.hpp`](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/src/viam/sdk/components/base.hpp).
-
-For more information on the base component API methods used in these examples, see the following resources:
-
-- [C++ SDK documentation for the `Base` class](https://cpp.viam.dev/classviam_1_1sdk_1_1Base.html)
-- [Base API methods](/reference/apis/components/base/)
-
-For more C++ module examples of varying complexity,see the [C++ SDK `examples` directory](https://github.com/viamrobotics/viam-cpp-sdk/tree/main/src/viam/examples/modules/).
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Write an entry point (main program) file
-
-A main entry point file starts the module, and adds the resource model.
-
-Follow the instructions below for the language you are using to write your module code:
-
-{{< tabs name="Sample SDK Main Program Code">}}
-{{% tab name="Python"%}}
-
-Create a <file>main.py</file> file to serve as the module's entry point file, which:
-
-- imports the custom model
-- defines a `main()` function that registers the model with the Python SDK
-- creates and starts the module
-
-For example, the following `main.py` file serves as the entry point file for the `MyBase` custom model.
-It imports the `MyBase` model from the `my_base.py` file that provides it, and defines a `main()` function that registers it.
-
-{{< expand "Click to view sample code for main.py" >}}
-
-```python {class="line-numbers linkable-line-numbers"}
-import asyncio
-
-from viam.components.base import Base
-from viam.module.module import Module
-from viam.resource.registry import Registry, ResourceCreatorRegistration
-from my_base import MyBase
-
-
-async def main():
-    """
-    This function creates and starts a new module, after adding all desired
-    resource models. Resource creators must be registered to the resource
-    registry before the module adds the resource model.
-    """
-    Registry.register_resource_creator(
-        Base.API,
-        MyBase.MODEL,
-        ResourceCreatorRegistration(MyBase.new_base, MyBase.validate_config))
-    module = Module.from_args()
-
-    module.add_model_from_registry(Base.API, MyBase.MODEL)
-    await module.start()
-
-if __name__ == "__main__":
-    asyncio.run(main())
-```
-
-{{< /expand >}}
-
-{{% /tab %}}
-{{% tab name="Go"%}}
-
-Create a <file>main.go</file> file to serve as the module's entry point file, which:
-
-- imports the custom model
-- defines a `main()` function that registers the model with the Viam Go SDK
-- creates and starts the module
-
-For example, the following `main.go` file serves as the entry point file for the `mybase` custom model.
-It imports the `mybase` model from the `my_base.go` file that provides it, and defines a `main()` function that registers it.
-
-{{< expand "Click to view sample code for main.go" >}}
-
-```go {class="line-numbers linkable-line-numbers"}
-// Package main is a module which serves the mybase custom model.
-package main
-
-import (
-    "context"
-
-    "go.viam.com/rdk/components/base"
-    "go.viam.com/rdk/logging"
-    "go.viam.com/rdk/module"
-    "go.viam.com/rdk/utils"
-
-    // Import your local package "mybase"
-    // NOTE: Update this path if your custom resource is in a different location,
-    // or has a different name:
-    "go.viam.com/rdk/examples/customresources/models/mybase"
-)
-
-func main() {
-    // NewLoggerFromArgs will create a logging.Logger at "DebugLevel" if
-    // "--log-level=debug" is an argument in os.Args and at "InfoLevel" otherwise.
-    utils.ContextualMain(mainWithArgs, module.NewLoggerFromArgs("mybase"))
-}
-
-func mainWithArgs(ctx context.Context, args []string, logger logging.Logger) (err error) {
-    myMod, err := module.NewModuleFromArgs(ctx, logger)
-    if err != nil {
-        return err
-    }
-
-    // Models and APIs add helpers to the registry during their init().
-    // They can then be added to the module here.
-    err = myMod.AddModelFromRegistry(ctx, base.API, mybase.Model)
-    if err != nil {
-        return err
-    }
-
-    err = myMod.Start(ctx)
-    defer myMod.Close(ctx)
-    if err != nil {
-        return err
-    }
-    <-ctx.Done()
-    return nil
-}
-```
-
-{{< /expand >}}
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-Create a <file>main.cpp</file> file to serve as the module's entry point file, which:
-
-- imports the custom model implementation and definitions
-- includes a `main()` function that registers the model with the Viam C++ SDK
-- creates and starts the module
-
-For example, the following `main.cpp` file serves as the entry point file for the `mybase` custom model.
-It imports the `mybase` model implementation from the `my_base.hpp` file that provides it, declares the model triplet `acme:my-custom-base-module:mybase`, and defines a `main()` function that registers it.
-
-{{< expand "Click to view sample code for main.cpp" >}}
-
-```cpp {class="line-numbers linkable-line-numbers"}
-#include <memory>
-#include <signal.h>
-
-#include <boost/log/trivial.hpp>
-#include <grpcpp/grpcpp.h>
-#include <grpcpp/server_context.h>
-
-#include <viam/api/common/v1/common.grpc.pb.h>
-#include <viam/api/component/generic/v1/generic.grpc.pb.h>
-#include <viam/api/robot/v1/robot.pb.h>
-
-#include <viam/sdk/components/base/base.hpp>
-#include <viam/sdk/components/component.hpp>
-#include <viam/sdk/config/resource.hpp>
-#include <viam/sdk/module/module.hpp>
-#include <viam/sdk/module/service.hpp>
-#include <viam/sdk/registry/registry.hpp>
-#include <viam/sdk/resource/resource.hpp>
-#include <viam/sdk/rpc/dial.hpp>
-#include <viam/sdk/rpc/server.hpp>
-
-#include "my_base.hpp"
-
-using namespace viam::sdk;
-
-int main(int argc, char** argv) {
-    API base_api = Base::static_api();
-    Model mybase_model("acme", "my-custom-base-module", "mybase");
-
-    std::shared_ptr<ModelRegistration> mybase_mr = std::make_shared<ModelRegistration>(
-        base_api,
-        mybase_model,
-        [](Dependencies deps, ResourceConfig cfg) { return std::make_unique<MyBase>(deps, cfg); },
-        MyBase::validate);
-
-    std::vector<std::shared_ptr<ModelRegistration>> mrs = {mybase_mr};
-    auto my_mod = std::make_shared<ModuleService>(argc, argv, mrs);
-    my_mod->serve();
-
-    return EXIT_SUCCESS;
-};
-```
-
-{{< /expand >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-#### (Optional) Configure logging
-
-If desired, you can configure your module to output log messages.
-Log messages appear on the [**LOGS** tab](/manage/troubleshoot/troubleshoot/#check-logs) for your machine in an easily-parsable and searchable manner.
-
-Log messages generated when your machine is offline are queued, and sent together when your machine connects to the internet once more.
-
-Add the following code to your module code to enable logging to Viam, depending on the language you using to code your module. You can log in this fashion from the model definition file or files, the entry point (main program) file, or both, depending on your logging needs:
-
-{{% alert title="Tip" color="tip" %}}
-The example code shown above under [Write your new resource model definition](#write-your-new-resource-model-definition) includes the requisite logging code already.
-{{% /alert %}}
-
-{{< tabs name="Configure logging">}}
-{{% tab name="Python"%}}
-
-To enable your Python module to write resource-level log messages to Viam, add the following lines to your code:
-
-```python {class="line-numbers linkable-line-numbers"}
-# Within some method, log information:
-self.logger.debug("debug info")
-self.logger.info("info")
-self.logger.warn("warning info")
-self.logger.error("error info")
-self.logger.exception("error info", exc_info=True)
-self.logger.critical("critical info")
-```
-
-Resource-level logs are recommended instead of global logs for modular resources, because they make it easier to determine which component or service an error is coming from.
-Resource-level error logs appear in the **ERROR LOGS** section of each resource's configuration card in the app.
-
-{{% alert title="Note" color="note" %}}
-In order to see resource-level debug logs when using your modular resource, you'll either need to run `viam-server` with the `-debug` option or [configure your machine or individual resource to display debug logs](/operate/reference/viam-server/#logging).
-{{% /alert %}}
-
-{{< expand "Click to see global logging" >}}
-
-If you need to publish to the global machine-level logs instead of using the recommended resource-level logging, you can follow this example:
-
-```python {class="line-numbers linkable-line-numbers" data-line="2,5"}
-# In your import block, import the logging package:
-from viam.logging import getLogger
-
-# Before your first class or function, define the LOGGER variable:
-LOGGER = getLogger(__name__)
-
-# in some method, log information
-LOGGER.debug("debug info")
-LOGGER.info("info info")
-LOGGER.warn("warn info")
-LOGGER.error("error info")
-LOGGER.exception("error info", exc_info=True)
-LOGGER.critical("critical info")
-```
-
-{{< /expand >}}
-
-{{% /tab %}}
-{{% tab name="Go"%}}
-
-To enable your Go module to write log messages to Viam, add the following lines to your code:
-
-```go {class="line-numbers linkable-line-numbers"}
-// In your import() block, import the logging package:
-import(
-       ...
-       "go.viam.com/rdk/logging"
-)
-// Alter your component to hold a logger
-type component struct {
-    ...
- logger logging.Logger
-}
-// Then, alter your component's constructor to save the logger:
-func init() {
- registration := resource.Registration[resource.Resource, *Config]{
-  Constructor: func(ctx context.Context, deps resource.Dependencies, conf resource.Config, logger logging.Logger) (resource.Resource, error) {
-     ...
-     return &component {
-         ...
-         logger: logger
-     }, nil
-  },
- }
- resource.RegisterComponent(...)
-}
-// Finally, when you need to log, use the functions on your component's logger:
-fn (c *component) someFunction(ctx context.Context, a int) {
-  // Log with severity info:
-  c.logger.CInfof(ctx, "performing some function with a=%v", a)
-  // Log with severity debug (using value wrapping):
-  c.logger.CDebugw(ctx, "performing some function", "a" ,a)
-  // Log with severity warn:
-  c.logger.CWarnw(ctx, "encountered warning for component", "name", c.Name())
-  // Log with severity error without a parameter:
-  c.logger.CError(ctx, "encountered an error")
-}
-```
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-`viam-server` automatically gathers all output sent to the standard output (`STDOUT`) in your C++ code and forwards it to Viam when a network connection is available.
-
-We recommend that you use a C++ logging library to assist with log message format and creation, such as the [Boost trivial logger](https://www.boost.org/doc/libs/1_84_0/libs/log/doc/html/log/tutorial/trivial_filtering.html):
-
-```cpp {class="line-numbers linkable-line-numbers"}
-#include <boost/log/trivial.hpp>
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Compile or package your module
-
-The final step to creating a new module is to create an executable file that `viam-server` can use to run your module on demand.
-
-This executable file:
-
-- runs your module when executed
-- takes a local UNIX socket as a command line argument
-- exits cleanly when sent a termination signal
-
-Depending on the language you are using to code your module, you may have options for how you create your executable file:
-
-{{% tabs %}}
-{{% tab name="Python: pyinstaller (recommended)" %}}
-
-The recommended approach for Python is to use [`PyInstaller`](https://pypi.org/project/pyinstaller/) to compile your module into a packaged executable: a standalone file containing your program, the Python interpreter, and all of its dependencies.
-When packaged in this fashion, you can run the resulting executable on your desired target platform or platforms without needing to install additional software or manage dependencies manually.
-
-To create a packaged executable:
-
-1. First, [create a Python virtual environment](/reference/sdks/python/python-venv/) in your module's directory to ensure your module has access to any required libraries.
-   Be sure you are within your Python virtual environment for the rest of these steps: your terminal prompt should include the name of your virtual environment in parentheses.
-
-1. Create a `requirements.txt` file containing a list of all the dependencies your module requires.
-   For example, a `requirements.txt` file with the following contents ensures that the Viam Python SDK (`viam-sdk`), PyInstaller (`pyinstaller`), and the Google API Python client (`google-api-python-client`) are installed:
-
-   ```sh { class="command-line" data-prompt="$"}
-   viam-sdk
-   pyinstaller
-   google-api-python-client
-   ```
-
-   Add additional dependencies for your module as needed.
-   See the [pip `requirements.txt` file documentation](https://pip.pypa.io/en/stable/reference/requirements-file-format/) for more information.
-
-1. Install the dependencies listed in your `requirements.txt` file within your Python virtual environment using the following command:
-
-   ```sh { class="command-line" data-prompt="$"}
-   python -m pip install -r requirements.txt -U
-   ```
-
-1. Then compile your module, adding the Google API Python client as a hidden import:
-
-   ```sh { class="command-line" data-prompt="$"}
-   python -m PyInstaller --onefile --hidden-import="googleapiclient" src/main.py
-   ```
-
-   If you need to include any additional data files to support your module, specify them using the `--add-data` flag:
-
-   ```sh { class="command-line" data-prompt="$"}
-   python -m PyInstaller --onefile --hidden-import="googleapiclient" --add-data src/arm/my_arm_kinematics.json:src/arm/ src/main.py
-   ```
-
-   By default, the output directory for the packaged executable is <file>dist</file>, and the name of the executable is derived from the name of the input script (in this case, main).
-
-We recommend you use PyInstaller with the [`build-action` GitHub action](https://github.com/viamrobotics/build-action) which provides a simple cross-platform build setup for multiple platforms: x86 and Arm Linux distributions, and macOS.
-Follow the instructions to [Update an existing module using a GitHub action](/operate/modules/advanced/manage-modules/#update-automatically-from-a-github-repo-with-cloud-build) to add the build configuration to your machine.
-
-With this approach, you can make a build script like the following to
-build your module, and configure the resulting executable (<file>dist/main</file>) as your module `"entrypoint"`:
-
-```sh { class="command-line"}
-#!/bin/bash
-set -e
-
-sudo apt-get install -y python3-venv
-python3 -m venv .venv
-. .venv/bin/activate
-pip3 install -r requirements.txt
-python3 -m PyInstaller --onefile --hidden-import="googleapiclient" src/main.py
-tar -czvf dist/archive.tar.gz dist/main
-```
-
-This script automates the process of setting up a Python virtual environment on a Linux arm64 machine, installing dependencies, packaging the Python module into a standalone executable using PyInstaller, and then compressing the resulting executable into a tarball.
-For more examples of build scripts see [Update an existing module using a GitHub action](/operate/modules/advanced/manage-modules/#update-automatically-from-a-github-repo-with-cloud-build).
-
-{{% alert title="Note" color="note" %}}
-
-PyInstaller does not support relative imports in entrypoints (imports starting with `.`).
-If you get `"ImportError: attempted relative import with no known parent package"`, set up a stub entrypoint as described on [GitHub](https://github.com/pyinstaller/pyinstaller/issues/2560).
-
-In addition, PyInstaller does not support cross-compiling: you must compile your module on the target architecture you wish to support.
-For example, you cannot run a module on a Linux `arm64` system if you compiled it using PyInstaller on a Linux `amd64` system.
-Viam makes this easy to manage by providing a build system for modules.
-Follow [these instructions](/cli/#using-the-build-subcommand) to automatically build for each system your module can support using Viam's [CLI](/cli/).
-
-{{% /alert %}}
-
-{{% /tab %}}
-{{% tab name="Python: venv" %}}
-
-Create a `run.sh` shell script that creates a new Python virtual environment, ensures that the package dependencies your module requires are installed, and runs your module.
-This is the recommended approach for modules written in Python:
-
-1. Create a `requirements.txt` file containing a list of all the dependencies your module requires.
-   For example, a `requirements.txt` file with the following contents ensures that the Viam Python SDK (`viam-sdk`) is installed:
-
-   ```sh { class="command-line" data-prompt="$"}
-   viam-sdk
-   ```
-
-   Add additional dependencies for your module as needed.
-   See the [pip `requirements.txt` file documentation](https://pip.pypa.io/en/stable/reference/requirements-file-format/) for more information.
-
-1. Add a shell script that creates a new virtual environment, installs the dependencies listed in `requirements.txt`, and runs the module entry point file `main.py`:
-
-   ```sh { class="command-line" data-prompt="$"}
-   #!/bin/sh
-   cd `dirname $0`
-
-   # Create a virtual environment to run our code
-   VENV_NAME="venv"
-   PYTHON="$VENV_NAME/bin/python"
-
-   python3 -m venv $VENV_NAME
-   $PYTHON -m pip install -r requirements.txt -U # remove -U if viam-sdk should not be upgraded whenever possible
-
-   # Be sure to use `exec` so that termination signals reach the python process,
-   # or handle forwarding termination signals manually
-   exec $PYTHON <your-src-dir-if-inside>/main.py $@
-   ```
-
-1. Make your shell script executable by running the following command in your terminal:
-
-   ```sh { class="command-line" data-prompt="$"}
-   sudo chmod +x <your-file-path-to>/run.sh
-   ```
-
-Using a virtual environment together with a `requirements.txt` file and a `run.sh` file that references it ensures that your module has access to any packages it requires during runtime.
-If you intend to share your module with other users, or to deploy it to a fleet of machines, this approach handles dependency resolution for each deployment automatically, meaning that there is no need to explicitly determine and install the Python packages your module requires to run on each machine that installs your module.
-See [prepare a Python virtual environment](/reference/sdks/python/python-venv/) for more information.
-
-{{% /tab %}}
-{{% tab name="Python: nuitka" %}}
-
-Use the [`nuitka` Python compiler](https://pypi.org/project/Nuitka/) to compile your module into a single executable file:
-
-1. In order to use Nuitka, you must install a [supported C compiler](https://github.com/Nuitka/Nuitka#c-compiler) on your machine.
-
-1. Then, [create a Python virtual environment](/reference/sdks/python/python-venv/) in your module's directory to ensure your module has access to any required libraries.
-   Be sure you are within your Python virtual environment for the rest of these steps: your terminal prompt should include the name of your virtual environment in parentheses.
-
-1. Create a `requirements.txt` file containing a list of all the dependencies your module requires.
-   For example, a `requirements.txt` file with the following contents ensures that the Viam Python SDK (`viam-sdk`) and Nuitka (`nuitka`) are installed:
-
-   ```sh { class="command-line" data-prompt="$"}
-   viam-sdk
-   nuitka
-   ```
-
-   Add additional dependencies for your module as needed.
-   See the [pip `requirements.txt` file documentation](https://pip.pypa.io/en/stable/reference/requirements-file-format/) for more information.
-
-1. Install the dependencies listed in your `requirements.txt` file within your Python virtual environment using the following command:
-
-   ```sh { class="command-line" data-prompt="$"}
-   python -m pip install -r requirements.txt -U
-   ```
-
-1. Then, compile your module using Nuitka with the following command:
-
-   ```sh { class="command-line" data-prompt="$"}
-   python -m nuitka --onefile src/main.py
-   ```
-
-   If you need to include any additional data files to support your module, specify them using the `--include-data-files` flag:
-
-   ```sh { class="command-line" data-prompt="$"}
-   python -m nuitka --onefile --include-data-files=src/arm/my_arm_kinematics.json src/main.py
-   ```
-
-Compiling your Python module in this fashion ensures that your module has access to any packages it requires during runtime.
-If you intend to share your module with other users, or to deploy it to a fleet of machines, this approach "bundles" your module code together with its required dependencies, making your module highly-portable across like architectures.
-
-However, used in this manner, Nuitka does not support relative imports (imports starting with `.`).
-In addition, Nuitka does not support cross-compiling: you can only compile your module on the target architecture you wish to support if using the Nutika approach.
-If you want to cross-compile your module, consider using a different local compilation method, or the [`module build start` command](/cli/#using-the-build-subcommand) to build your module on a cloud build host, which supports building for multiple platforms.
-For example, you cannot run a module on a Linux `arm64` system if you compiled it using Nuitka on a Linux `amd64` system.
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Use Go to compile your module into a single executable:
-
-- Navigate to your module directory in your terminal.
-- Run `go build` to compile your entry point (main program) file <file>main.go</file> and all other <file>.go</file> files in the directory, building your module and all dependencies into a single executable file.
-- Run `ls` in your module directory to find the executable, which should have the same name as the module directory.
-
-Compiling your Go module also generates the `go.mod` and `go.sum` files that define dependency resolution in Go.
-
-See the [Go compilation documentation](https://pkg.go.dev/cmd/go#hdr-Compile_packages_and_dependencies) for more information.
-
-{{% /tab %}}
-{{% tab name="C++" %}}
-
-Create a <file>CMakeLists.txt</file> file to define how to compile your module and a <file>run.sh</file> file to wrap your executable, and then use C++ to compile your source files into a single executable:
-
-1. Create a <file>CMakeLists.txt</file> file in your module directory to instruct the compiler how to compile your module.
-   For example, the following basic configuration downloads the C++ SDK and handles compile-time linking for a module named `my-base`:
-
-   ```sh {class="line-numbers linkable-line-numbers"}
-   cmake_minimum_required(VERSION 3.7 FATAL_ERROR)
-
-   project(my-base LANGUAGES CXX)
-
-   set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
-
-   include(FetchContent)
-   FetchContent_Declare(
-     viam-cpp-sdk
-     GIT_REPOSITORY https://github.com/viamrobotics/viam-cpp-sdk.git
-     GIT_TAG main
-     # SOURCE_DIR ${CMAKE_SOURCE_DIR}/../viam-cpp-sdk
-     CMAKE_ARGS -DVIAMCPPSDK_USE_DYNAMIC_PROTOS=ON
-     FIND_PACKAGE_ARGS
-   )
-   FetchContent_MakeAvailable(viam-cpp-sdk)
-
-   FILE(GLOB sources *.cpp)
-   add_executable(my-base ${sources})
-   target_link_libraries(my-base PRIVATE viam-cpp-sdk::viamsdk)
-   ```
-
-1. Create a <file>run.sh</file> file in your module directory to wrap the executable and perform basic sanity checks at runtime.
-
-   The following example shows a simple configuration that runs a module named `my-base`:
-
-   ```sh {class="line-numbers linkable-line-numbers"}
-   #!/usr/bin/env bash
-
-   # bash safe mode
-   set -euo pipefail
-
-   cd $(dirname $0)
-   exec ./my-base $@
-   ```
-
-1. Use C++ to compile and obtain a single executable for your module:
-
-   1. Create a new <file>build</file> directory within your module directory:
-
-      ```sh { class="command-line"}
-      mkdir build
-      cd build
-      ```
-
-   1. Build and compile your module:
-
-      ```sh { class="command-line"}
-      cmake .. -G Ninja
-      ninja all
-      ninja install
-      ```
-
-   1. Run `ls` in your module's <file>build</file> directory to find the compiled executable, which should have the same name as the module directory (`my-base` in these examples):
-
-For more information on building a module in C++, see the [C++ SDK Build Documentation](https://github.com/viamrobotics/viam-cpp-sdk/blob/main/BUILDING.md).
-
-{{% /tab %}}
-{{% /tabs %}}
-
-### (Optional) Create a README
-
-To provide usage instructions for any modular resources in your module, you should create a <file>README.md</file> file following this template:
-
-{{< expand "Click to view template" >}}
-
-Strings of the form `<INSERT X>` indicate placeholders that you need to replace with your values.
-
-{{< tabs >}}
-{{% tab name="Template" %}}
-
-````md
-# [`<INSERT MODULE NAME>` module](<INSERT LINK TO MODULE REPO>)
-
-This [module](https://docs.viam.com/operate/modules/configure-modules/) implements the [`<INSERT API TRIPLET>` API]<INSERT LINK TO DOCS (if applicable)> in an <INSERT MODEL> model.
-With this model, you can...
-
-## Requirements
-
-_Add instructions here for any requirements._
-
-```bash
-
-```
-
-## Configure your <INSERT MODEL NAME> <INSERT API NAME>
-
-Navigate to your machine's **CONFIGURE** tab.
-[Add <INSERT COMPONENT TYPE / INSERT RESOURCE NAME> to your machine](/operate/modules/configure-modules/#configure-hardware-or-software-on-your-machine).
-
-On the new component panel, copy and paste the following attribute template into your <INSERT API NAME>’s attributes field:
-
-```json
-{
-  <INSERT SAMPLE ATTRIBUTES>
-}
-```
-
-### Attributes
-
-The following attributes are available for `<INSERT MODEL TRIPLET>` <INSERT API NAME>s:
-
-| Name    | Type   | Required?    | Description |
-| ------- | ------ | ------------ | ----------- |
-| `todo1` | string | **Required** | TODO        |
-| `todo2` | string | Optional     | TODO        |
-
-### Example configuration
-
-```json
-{
-  <INSERT SAMPLE CONFIGURATION(S)>
-}
-```
-
-### Next steps
-
-_Add any additional information you want readers to know and direct them towards what to do next with this module._
-_For example:_
-
-- To test your...
-- To write code against your...
-
-## Troubleshooting
-
-_Add troubleshooting notes here._
-````
-
-{{% /tab %}}
-{{% tab name="Example" %}}
-
-````md
-# [`agilex-limo` module](https://app.viam.com/module/viam/agilex-limo)
-
-This module implements the [`rdk:component:base` API](https://docs.viam.com/reference/apis/components/base/) in an `agilex` model for the [AgileX LIMO](https://global.agilex.ai/products/limo-pro) base to be used with `viam-server`.
-This driver supports differential, ackermann, and omni directional steering modes over the serial port.
-
-## Configure your `agilex-limo` base
-
-> [!NOTE]
-> Before configuring your base, you must add a machine on [Viam](https://app.viam.com).
-
-Navigate to the **CONFIGURE** tab of your machine’s page.
-[Add `base` / `agilex-limo` to your machine](/operate/modules/configure-modules/#configure-hardware-or-software-on-your-machine).
-
-On the new component panel, copy and paste the following attribute template into your base’s attributes field:
-
-```json
-{
-  "drive_mode": "<ackermann|differential|omni>",
-  "serial_path": "<your-serial-path>"
-}
-```
-
-> [!NOTE]
-> For more information, see [Configure hardware on your machine](/operate/modules/configure-modules/#configure-hardware-or-software-on-your-machine).
-
-### Attributes
-
-The following attributes are available for `viam:base:agilex-limo` bases:
-
-<!-- prettier-ignore -->
-| Name          | Type   | Required?    | Description |
-| ------------- | ------ | ------------ | ----------- |
-| `drive_mode`  | string | **Required** | LIMO [steering mode](https://docs.trossenrobotics.com/agilex_limo_docs/operation/steering_modes.html#switching-steering-modes). Options: `differential`, `ackermann`, `omni` (mecanum). |
-| `serial_path` | string | Optional     | The full filesystem path to the serial device, starting with <file>/dev/</file>. With your serial device connected, you can run `sudo dmesg \| grep tty` to show relevant device connection log messages, and then match the returned device name, such as `ttyTHS1`, to its device file, such as <file>/dev/ttyTHS1</file>. If you omit this attribute, Viam will attempt to automatically detect the path.<br>Default: `/dev/ttyTHS1` |
-
-### Example configurations:
-
-```json
-{
-  "drive_mode": "differential"
-}
-```
-
-```json
-{
-  "drive_mode": "omni",
-  "serial_path": "/dev/ttyTHS1"
-}
-```
-
-## Next steps
-
-- To test your base, go to the [**CONTROL** tab](https://docs.viam.com/manage/troubleshoot/teleoperate/default-interface/).
-- To write code against your base, use one of the [available SDKs](https://docs.viam.com/reference/sdks/).
-- To view examples using a base component, explore [these tutorials](https://docs.viam.com/tutorials/).
-
-## Local development
-
-This module is written in Go.
-
-To build: `make limobase`<br>
-To test: `make test`
-````
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< /expand >}}
-
-## Test your module locally
-
-{{% alert title="Tip" color="tip" %}}
-
-If you would like to test your module locally against a target platform other than your development machine before uploading it, you can for example sync your code to an SBC with architecture that matches your target platform, and test your module there to verify that any code changes you have made work as expected on your target platform.
-
-{{% /alert %}}
-
-To use a local module on your machine, first make sure any physical hardware implemented in your module is connected to your machine's computer.
-Add the module to your machine's config, then add the component or service it implements:
-
-1. Navigate to the **CONFIGURE** tab of your machine's page.
-
-1. Click the **+** (Create) icon next to your machine part in the left-hand menu and select **Local module**, then **Local module**.
-
-1. Enter a **Name** for this instance of your module.
-
-1. Enter the module's **Executable path**.
-   This path must be the absolute path on your machine's filesystem to either:
-
-   - the module's executable file, such as `run.sh` or a compiled binary.
-   - a [packaged tarball](https://www.cs.swarthmore.edu/~newhall/unixhelp/howto_tar.html) of your module, ending in `.tar.gz` or `.tgz`.
-     If you are providing a tarball file in this field, be sure that your packaged tarball contains your module's [`meta.json` file](/operate/modules/advanced/metajson/) within it.
-
-1. Then, click the **Create** button, and click **Save** in the upper right corner to save your config.
-
-1. Still on your machine's **CONFIGURE** tab, click the **+** (Create) icon next to your machine part in the left-hand menu.
-
-1. Select **Local module**, then select **Local component** or **Local service**.
-
-1. Select or enter the {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet">}} of your modular resource's {{< glossary_tooltip term_id="model" text="model" >}}.
-
-   {{<imgproc src="/how-tos/sensor-module-config.png" resize="600x" style="width: 300px" alt="Configuring a local component after the local module is configured" class="shadow" >}}
-
-1. Select the type of modular resource provided by your module, such as a [camera](/operate/reference/components/camera/), from the dropdown menu.
-
-1. Enter a name for this instance of your modular resource.
-   This name must be different from the module name.
-
-1. Click **Create** to create the modular resource provided by the local module.
-
-Once you've added your local module using steps 1-5, you can repeat steps 6-11 to add as many additional instances of your modular resource as you need.
-
-## Upload your module to the modular resource registry
-
-Once you are satisfied with the state of your module, you can upload your module to the Viam Registry to:
-
-- share your module with other Viam users
-- deploy your module to a fleet of machines from a central interface
-
-See [Update and manage modules you created](/operate/modules/advanced/manage-modules/) for instructions.
-
-## Deploy your module to more machines
-
-You have now created a module, and are ready to deploy it to a fleet of machines.
-There are two ways to deploy a module:
-
-- Through the Viam Registry: Once you have uploaded your new module to the Viam Registry, [add the module to one or more machines](/operate/modules/configure-modules/#configure-hardware-or-software-on-your-machine).
-  You can also choose to configure [automated uploads for new module versions](/operate/modules/advanced/manage-modules/#update-automatically-from-a-github-repo-with-cloud-build) through a continuous integration (CI) workflow, using a GitHub Action if desired, greatly simplifying how you push changes to your module to the registry as you make them.
-- As a local module (without uploading it to Viam), as you did in the [Test your module locally step above](#test-your-module-locally).
-  This is a great way to test, but if you'd like to use the module on more machines it's easiest to add it to the registry either publicly or privately.
-
-Often, developers first test their new module by deploying it as a local module to a test machine.
-With a local installation, you can test your module in a controlled environment to confirm that it functions as expected, and make changes to your module as needed.
-
-## Next steps
-
-For instructions on how to update or delete modules you've created, see the following how-to guide:
-
-{{< cards >}}
-{{% card link="/operate/modules/advanced/manage-modules/" %}}
-{{< /cards >}}
-
-To read more about module development at Viam, check out these tutorials that create modules:
-
-{{< cards >}}
-{{% card link="/tutorials/custom/custom-base-dog/" %}}
-{{% card link="/tutorials/configure/pet-photographer/" %}}
-{{< /cards >}}
diff --git a/docs/operate/modules/advanced/dependencies.md b/docs/operate/modules/advanced/dependencies.md
deleted file mode 100644
index 61638be025..0000000000
--- a/docs/operate/modules/advanced/dependencies.md
+++ /dev/null
@@ -1,496 +0,0 @@
----
-title: "Access machine resources from within a module"
-linkTitle: "Module dependencies"
-weight: 26
-layout: "docs"
-type: "docs"
-description: "From within a modular resource, you can access other machine resources using dependencies."
-aliases:
-  - /operate/modules/other-hardware/dependencies/
-  - /operate/modules/support-hardware/create-module/dependencies/
-date: "2025-11-11"
----
-
-From within a modular resource, you can access other machine {{< glossary_tooltip term_id="resource" text="resources" >}} using dependencies.
-
-## Types of dependencies
-
-There are two types of dependencies:
-
-- **Required dependencies**: A dependency should be designated **required** if a module cannot function without it.
-  `viam-server` will not start the resource until all required dependencies are started and functioning.
-- **Optional dependencies**: A dependency should be designated **optional** if a module can function without it.
-  If an optional dependency is not available when the modular resource starts, the resource will start without it and reconfigure when the optional dependency becomes available.
-  `viam-server` attempts to start the optional dependency every 5 seconds.
-
-## Implementation
-
-When implementing a modular resource with dependencies, the validation and constructor or reconfiguration functions ensure the resource has access to the dependencies:
-
-**Example:** Imagine a camera component that implements logic to capture images from another camera only if an ultrasonic sensor determines that someone is nearby.
-The camera stores a picture only if someone is detected nearby.
-To implement this, you would make the sensor and the camera required dependencies of the camera component.
-
-Ultrasonic sensors only determine that something is near, not necessarily a person.
-To make the camera component capture images more reliably only if a person is nearby, you could add a vision service.
-To make the camera component work with and without a vision service, you would make the vision service an optional dependency.
-
-{{< table >}}
-{{% tablestep start=1 %}}
-**Implement resource config validation.**
-
-To keep modular resources flexible, the names of the resources that are dependencies get passed in the resource's configuration.
-For example:
-
-```json {class="line-numbers linkable-line-numbers" data-line="6-8"}
-{
-  "name": "proximity-camera",
-  "api": "rdk:component:camera",
-  "model": "exampleorg:examplemodule:examplecamera",
-  "attributes": {
-    "camera_name": "camera-1",
-    "sensor_name": "sensor-1",
-    "vision_name": "vision-1"
-  }
-}
-```
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-The `validate_config` method must:
-
-- Check that required dependencies are present in the configuration.
-- Return a list of the names of required dependencies and a list of the names of optional dependencies.
-
-```python {class="line-numbers linkable-line-numbers"}
-# Add to imports
-from viam.components.camera import *
-from viam.components.sensor import *
-from viam.services.vision import *
-from typing import cast
-
-
-@classmethod
-def validate_config(
-    cls, config: ComponentConfig
-) -> Tuple[Sequence[str], Sequence[str]]:
-    req_deps = []
-    opt_deps = []
-    fields = config.attributes.fields
-
-    if "camera_name" not in fields:
-        raise Exception("missing required camera_name attribute")
-    elif not fields["camera_name"].HasField("string_value"):
-        raise Exception("camera_name must be a string")
-    camera_name = fields["camera_name"].string_value
-    if not camera_name:
-        raise ValueError("camera_name cannot be empty")
-    req_deps.append(camera_name)
-
-    if "sensor_name" not in fields:
-        raise Exception("missing required sensor_name attribute")
-    elif not fields["sensor_name"].HasField("string_value"):
-        raise Exception("sensor_name must be a string")
-    sensor_name = fields["sensor_name"].string_value
-    if not sensor_name:
-        raise ValueError("sensor_name cannot be empty")
-    req_deps.append(sensor_name)
-
-    # Optional dependencies may not be present in the config
-    if "vision_name" in fields:
-        if not fields["vision_name"].HasField("string_value"):
-            raise Exception("vision_name must be a string")
-        vision_name = fields["vision_name"].string_value
-        if not vision_name:
-            raise ValueError("vision_name cannot be empty")
-        opt_deps.append(vision_name)
-
-    return req_deps, opt_deps
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-In your resource's `Config` struct, add the dependency attribute name.
-For example:
-
-```go {class="line-numbers linkable-line-numbers"}
-type Config struct {
-  CameraName string `json:"camera_name"`
-  SensorName string `json:"sensor_name"`
-  VisionName string `json:"vision_name"`
-}
-```
-
-The `Validate` method must:
-
-- Check that required dependencies are present in the configuration.
-- Return a list of the names of required dependencies and a list of the names of optional dependencies.
-
-```go {class="line-numbers linkable-line-numbers"}
-func (cfg *Config) Validate(path string) (requiredDeps []string, optionalDeps []string, err error) {
-  var reqDeps []string
-  var optDeps []string
-  if cfg.CameraName == "" {
-    return nil, nil, resource.NewConfigValidationFieldRequiredError(path, "camera_name")
-  }
-  reqDeps = append(reqDeps, cfg.CameraName)
-
-  if cfg.SensorName == "" {
-    return nil, nil, resource.NewConfigValidationFieldRequiredError(path, "sensor_name")
-  }
-  reqDeps = append(reqDeps, cfg.SensorName)
-
-  if cfg.VisionName != "" {
-    optDeps = append(optDeps, cfg.VisionName)
-  }
-
-  return reqDeps, optDeps, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-
-Accessing dependencies from the resource works differently for different programming languages:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-To be able to access the dependencies, use the `reconfigure` method to:
-
-- Access the dependency by using its name as a key in the `dependencies` mapping.
-- Cast the dependency to the correct type and store it.
-
-```python {class="line-numbers linkable-line-numbers"}
-def reconfigure(
-    self, config: ComponentConfig, dependencies: Mapping[ResourceName, ResourceBase]
-):
-    camera_name = config.attributes.fields["camera_name"].string_value
-    camera_resource = dependencies[Camera.get_resource_name(camera_name)]
-    self.camera = cast(Camera, camera_resource)
-
-    # If you need to use the camera name in your module,
-    # for example to pass it to a vision service method,
-    # you can store it in an instance variable.
-    self.camera_name = camera_name
-
-    sensor_name = config.attributes.fields["sensor_name"].string_value
-    sensor_resource = dependencies[Sensor.get_resource_name(sensor_name)]
-    self.sensor = cast(Sensor, sensor_resource)
-
-    # Optional dependencies may not be present in the config
-    self.vision_svc = None
-    if "vision_name" in config.attributes.fields:
-        vision_name = config.attributes.fields["vision_name"].string_value
-
-        # For optional dependencies, use .get() and handle None
-        vision_resource = dependencies.get(VisionClient.get_resource_name(vision_name))
-        if vision_resource is not None:
-            self.vision_svc = cast(VisionClient, vision_resource)
-
-    return super().reconfigure(config, dependencies)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Add the dependency to the `<module-name><resource-name>` struct:
-
-```go {class="line-numbers linkable-line-numbers" data-line="7-9"}
-type myModuleMyCamera struct {
-  resource.AlwaysRebuild
-
-  name resource.Name
-  logger logging.Logger
-  cfg    *Config
-  camera camera.Camera
-  sensor sensor.Sensor
-  vision vision.Service
-
-  cancelCtx  context.Context
-  cancelFunc func()
-}
-```
-
-Then, use your resource's constructor to access and store the dependency:
-
-```go {class="line-numbers linkable-line-numbers" data-line=""}
-// Add to import
-import (
-    camera "go.viam.com/rdk/components/camera"
-    sensor "go.viam.com/rdk/components/sensor"
-    vision "go.viam.com/rdk/services/vision"
-)
-
-func NewMyCamera(ctx context.Context, deps resource.Dependencies,
-  name resource.Name, conf *Config, logger logging.Logger) (camera.Camera, error) {
-
-  cancelCtx, cancelFunc := context.WithCancel(context.Background())
-
-  s := &myModuleMyCamera{
-    name:       name,
-    logger:     logger,
-    cfg:        conf,
-    cancelCtx:  cancelCtx,
-    cancelFunc: cancelFunc,
-  }
-  camera, err := camera.FromDependencies(deps, conf.CameraName)
-  if err != nil {
-    return nil, errors.New("failed to get camera dependency")
-  }
-  s.camera = camera
-
-  sensor, err := sensor.FromDependencies(deps, conf.SensorName)
-  if err != nil {
-    return nil, errors.New("failed to get sensor dependency")
-  }
-  s.sensor = sensor
-
-  // optional dependency
-  if conf.VisionName != "" {
-      vision, err := vision.FromDependencies(deps, conf.VisionName)
-      if err == nil {
-          s.vision = vision
-      }
-  }
-
-  return s, nil
-}
-```
-
-{{% alert title="Need to maintain state when reconfiguring?" color="note" %}}
-
-Most Go modules use `resource.AlwaysRebuild` within the `<module-name><resource-name>` struct, which rebuilds the resource every time the module is reconfigured.
-
-If you need to maintain the state of your resource, see [(Optional) Set up model configuration options](/operate/modules/write-a-driver-module/#6-handle-reconfiguration-optional).
-
-{{% /alert %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{% tablestep %}}
-
-You can now call API methods on dependency resources within your module, for example:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python {class="line-numbers linkable-line-numbers"}
-# Add to imports
-from viam.utils import from_dm_from_extra
-from viam.errors import NoCaptureToStoreError
-
-
-async def get_images(
-    self,
-    *,
-    filter_source_names: Optional[Sequence[str]] = None,
-    extra: Optional[Dict[str, Any]] = None,
-    timeout: Optional[float] = None,
-    **kwargs
-) -> Tuple[Sequence[NamedImage], ResponseMetadata]:
-    images, metadata = await self.camera.get_images()
-    readings = await self.sensor.get_readings()
-
-    # If called by the data manager to store image
-    # only return an image if a person is nearby
-    if from_dm_from_extra(extra):
-        if readings["distance"] <= 5:
-            if self.vision_svc:
-                detections = await self.vision_svc.get_detections(images[0])
-                for detection in detections:
-                    if detection.class_name == "Person":
-                        return images, metadata
-                raise NoCaptureToStoreError()
-            else:
-                return images, metadata
-        # No person nearby
-        raise NoCaptureToStoreError()
-
-    return images, metadata
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go {class="line-numbers linkable-line-numbers"}
-// Add to imports
-import (
-  "go.viam.com/rdk/data"
-)
-
-func (s *myModuleMyCamera) Images(ctx context.Context, filterSourceNames []string, extra map[string]interface{}) ([]camera.NamedImage, resource.ResponseMetadata, error) {
-    images, responseMetadata, err := s.camera.Images(ctx, filterSourceNames, extra)
-    if err != nil {
-        return nil, resource.ResponseMetadata{}, err
-    }
-
-    readings, err := s.sensor.Readings(ctx, nil)
-    if err != nil {
-        return nil, resource.ResponseMetadata{}, err
-    }
-
-    // Check if readings["distance"] <= 5
-    if distanceVal, ok := readings["distance"]; ok {
-        var distance float64
-        switch v := distanceVal.(type) {
-        case float64:
-            distance = v
-        case int:
-            distance = float64(v)
-        case int64:
-            distance = float64(v)
-        default:
-            return nil, resource.ResponseMetadata{}, fmt.Errorf("unable to convert sensor reading 'distance' to numeric type: got %T", distanceVal)
-        }
-
-        if distance <= 5.0 {
-            // Check if optional vision service is available
-            if s.vision != nil && len(images) > 0 {
-                img, err := images[0].Image(ctx)
-                if err != nil {
-                    return nil, resource.ResponseMetadata{}, err
-                }
-                detections, err := s.vision.Detections(ctx, img, nil)
-                if err != nil {
-                    return nil, resource.ResponseMetadata{}, err
-                }
-
-                for _, detection := range detections {
-                    if detection.Label() == "Person" {
-                        return images, responseMetadata, nil
-                    }
-                }
-                if extra[data.FromDMString] == true {
-                    return nil, resource.ResponseMetadata{}, errors.New("no capture to store")
-                }
-            } else {
-                return images, responseMetadata, nil
-            }
-        }
-    }
-
-    // If called by the data manager to store image
-    // return error if no person nearby
-    if extra[data.FromDMString] == true {
-        return nil, resource.ResponseMetadata{}, errors.New("no capture to store")
-    }
-    return images, responseMetadata, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tablestep %}}
-{{< /table >}}
-
-For more information on capturing data only if conditions are met, see [Pet photographer](/tutorials/configure/pet-photographer/).
-
-{{% hiddencontent %}}
-There is currently no SDK method to directly access configuration attributes of dependencies in Python or Go.
-However, you can use [`GetRobotPart`](/reference/apis/fleet/#getrobotpart) to return information including the entire configuration of a machine part, and then access the configuration attributes of the dependency from there.
-
-To learn how to use the Fleet management API from a module, see [Access platform APIs from within a module](/operate/modules/advanced/platform-apis/).
-{{% /hiddencontent %}}
-
-For full examples of modules with dependencies, see the [Desk Safari tutorial](/operate/hello-world/tutorial-desk-safari/) or [Viam complex module examples on GitHub](https://github.com/viamrobotics/viam-python-sdk/tree/main/examples/complex_module/src).
-
-## Special case: The `builtin` motion service
-
-The motion service is available by default as part of `viam-server`.
-This default motion service is available using the resource name `builtin` even though it does not appear in your machine config.
-
-This example shows how to access the default motion service:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python {class="line-numbers linkable-line-numbers"}
-# Add to imports
-from viam.services.motion import *
-
-
-# Return the motion service as a dependency
-@classmethod
-def validate_config(
-    cls, config: ComponentConfig
-) -> Tuple[Sequence[str], Sequence[str]]:
-    req_deps = []
-    req_deps.append("rdk:service:motion/builtin")
-    return req_deps, []
-
-
-# Get and store motion service instance
-def reconfigure(
-    self, config: ComponentConfig, dependencies: Mapping[
-      ResourceName, ResourceBase]
-):
-    motion_resource = dependencies[MotionClient.get_resource_name("builtin")]
-    self.motion_service = cast(MotionClient, motion_resource)
-
-    return super().reconfigure(config, dependencies)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go {class="line-numbers linkable-line-numbers"}
-// Add to imports
-import (
-  motion "go.viam.com/rdk/services/motion"
-)
-
-// Return the motion service as a dependency
-func (cfg *Config) Validate(path string) ([]string, []string, error) {
-  deps := []string{motion.Named("builtin").String()}
-  return deps, nil, nil
-}
-
-// Add motion service to <module-name><resource-name> struct
-type myModuleMyCamera struct {
-  resource.AlwaysRebuild
-
-  name resource.Name
-
-  logger logging.Logger
-  cfg    *Config
-  motion motion.Service
-
-  cancelCtx  context.Context
-  cancelFunc func()
-}
-
-// Get and store motion service instance
-func NewMyCamera(ctx context.Context, deps resource.Dependencies,
-  name resource.Name, conf *Config, logger logging.Logger) (camera.Camera, error) {
-
-  cancelCtx, cancelFunc := context.WithCancel(context.Background())
-
-  s := &myModuleMyCamera{
-    name:       name,
-    logger:     logger,
-    cfg:        conf,
-    cancelCtx:  cancelCtx,
-    cancelFunc: cancelFunc,
-  }
-
-  motion, err := motion.FromDependencies(deps, "builtin")
-  if err != nil {
-    return nil, errors.New("failed to get motion dependency")
-  }
-  s.motion = motion
-
-  return s, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
diff --git a/docs/operate/modules/advanced/logging.md b/docs/operate/modules/advanced/logging.md
deleted file mode 100644
index 512605b103..0000000000
--- a/docs/operate/modules/advanced/logging.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: "Module logging"
-linkTitle: "Module logging"
-weight: 45
-layout: "docs"
-type: "docs"
-description: "Use logging with modules"
----
-
-From modules you can log messages at the [resource level](#resource-level-logging) or at the [machine level](#machine-level-logging).
-
-## Resource-level logging
-
-The following log severity levels are available for resource logs:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python {class="line-numbers linkable-line-numbers"}
-# Within some method, log information:
-self.logger.debug("debug info")
-self.logger.info("info")
-self.logger.warn("warning info")
-self.logger.error("error info")
-self.logger.exception("error info", exc_info=True)
-self.logger.critical("critical info")
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go {class="line-numbers linkable-line-numbers"}
-fn (c *component) someFunction(ctx context.Context, a int) {
-  // Log with severity info:
-  c.logger.CInfof(ctx, "performing some function with a=%v", a)
-  // Log with severity debug (using value wrapping):
-  c.logger.CDebugw(ctx, "performing some function", "a" ,a)
-  // Log with severity warn:
-  c.logger.CWarnw(ctx, "encountered warning for component", "name", c.Name())
-  // Log with severity error without a parameter:
-  c.logger.CError(ctx, "encountered an error")
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Resource-level logs are recommended instead of global logs for modular resources, because they make it easier to determine which component or service an error is coming from.
-Resource-level error logs appear in the <strong>ERROR LOGS</strong> section of each resource's configuration card in the app.
-
-{{% alert title="Note" color="note" %}}
-In order to see resource-level debug logs when using your modular resource, you'll either need to run `viam-server` with the `-debug` option or [configure your machine or individual resource to display debug logs](/operate/reference/viam-server/#logging).
-{{% /alert %}}
-
-## Machine-level logging
-
-If you need to publish to the global machine-level logs instead of using the recommended resource-level logging, you can follow this example:
-
-```python {class="line-numbers linkable-line-numbers" data-line="2,5"}
-# In your import block, import the logging package:
-from viam.logging import getLogger
-
-# Before your first class or function, define the LOGGER variable:
-LOGGER = getLogger(__name__)
-
-# in some method, log information
-LOGGER.debug("debug info")
-LOGGER.info("info info")
-LOGGER.warn("warn info")
-LOGGER.error("error info")
-LOGGER.exception("error info", exc_info=True)
-LOGGER.critical("critical info")
-```
diff --git a/docs/operate/modules/advanced/manage-modules.md b/docs/operate/modules/advanced/manage-modules.md
deleted file mode 100644
index 30281aed6d..0000000000
--- a/docs/operate/modules/advanced/manage-modules.md
+++ /dev/null
@@ -1,456 +0,0 @@
----
-title: "Update and manage modules you created"
-linkTitle: "Update and manage modules"
-type: "docs"
-weight: 27
-images: ["/registry/create-module.svg"]
-icon: true
-tags: ["modular resources", "components", "services", "registry"]
-description: "Update or delete your existing modules, or change their privacy settings."
-aliases:
-  - /use-cases/deploy-code/
-  - /use-cases/manage-modules/
-  - /how-tos/manage-modules/
-  - /operate/modules/other-hardware/manage-modules/
-languages: []
-viamresources: []
-platformarea: ["registry"]
-level: "Beginner"
-date: "2024-06-30"
-# updated: ""  # When the tutorial was last entirely checked
-cost: "0"
----
-
-After you [create and upload a module](/operate/modules/write-a-driver-module/), you can update, delete, or change its visibility settings.
-
-For information on pinning module deployments to versions, see [Module versioning](/operate/modules/advanced/module-configuration/#module-versioning).
-
-## Update a module
-
-Once your module is in the [registry](https://app.viam.com/registry), there are two ways to update it:
-
-- [Update automatically](#update-automatically-from-a-github-repo-with-cloud-build) using GitHub Actions: Recommended for ongoing projects with continuous integration (CI) workflows, or if you want to build for multiple platforms.
-
-  - If you enabled cloud build when you generated your module, the GitHub Actions are already set up for you.
-
-- [Update manually](#update-manually) using the [Viam CLI](/cli/): Fine for small projects with one contributor.
-
-### Update automatically from a GitHub repo with cloud build
-
-Use [GitHub Actions](https://docs.github.com/actions) to automatically build and deploy your new module version when you create a new release in GitHub:
-
-1. Edit your module code and update the [`meta.json`](/operate/modules/advanced/metajson/) file if needed.
-   For example, if you've changed the module's functionality, update the description in the `meta.json` file.
-
-   {{% alert title="Important" color="note" %}}
-   Make sure the `url` field contains the URL of the GitHub repo that contains your module code.
-   This field is required for cloud build to work.
-   {{% /alert %}}
-
-1. Push your changes to your module GitHub repository.
-
-   {{% alert title="Tip" color="tip" %}}
-
-   If you used `viam module generate` to create your module and enabled cloud build, and you followed all the [steps to publish your module with PyInstaller](/operate/modules/deploy-a-module/#3-deploy-with-cloud-build-recommended) including adding API keys for the build action, all you need to do to trigger a new build is publish a release in GitHub as you did when you first published the module.
-
-   {{% /alert %}}
-
-1. If you did not use the Viam CLI generator and enable cloud build, you can set up one of the following GitHub Actions up manually:
-
-   {{< tabs >}}
-   {{% tab name="build-action (Recommended)" %}}
-
-   The `build-action` GitHub action provides a cross-platform build setup for multiple platforms: x86, ARM Linux, and macOS.
-
-   In your repository, create a workflow file called <FILE>build.yml</FILE> in the <FILE>.github/workflows<FILE> directory:
-
-   ```yaml
-   on:
-     release:
-       types: [published]
-
-   jobs:
-     publish:
-       runs-on: ubuntu-latest
-       steps:
-         - uses: actions/checkout@v3
-         - uses: viamrobotics/build-action@v1
-           with:
-             version: ${{ github.ref_name }}
-             ref: ${{ github.sha }}
-             key-id: ${{ secrets.viam_key_id }}
-             key-value: ${{ secrets.viam_key_value }}
-             token: ${{ github.token }} # only required for private git repos
-   ```
-
-The `build-action` GitHub action relies on a build command that you need to specify in the <file>meta.json</file> file.
-At the end of your <file>meta.json</file>, add the build configuration:
-
-<!-- { {< tabs >}}
-{ {% tab name="Single Build File" %}} -->
-
-```json {class="line-numbers linkable-line-numbers" data-line="5-9"}
-{
-  "module_id": "example-module",
-  ...
-  "build": {
-    "setup": "./setup.sh", // optional - command for one-time setup
-    "build": "./build.sh", // command that will build your module's tarball
-    "path" : "dist/archive.tar.gz", // optional - path to your built module tarball
-    "arch" : ["linux/amd64", "linux/arm64", "darwin/arm64"], // architecture(s) to build for
-    "darwin_deps" : ["go", "x264", "nlopt-static"] // optional - Homebrew dependencies for Darwin builds. Explicitly pass `[]` for empty.
-  }
-}
-```
-
-{{% expand "Cloud build configuration attributes" %}}
-
-<!-- prettier-ignore -->
-| Attribute | Inclusion | Description |
-| --------- | --------- | ----------- |
-| `"setup"` | Optional | Command to run for setting up the build environment. |
-| `"build"` | **Required** | Command to run to build the module tarball. |
-| `"path"` | Optional | Path to the build module tarball. |
-| `"arch"` | **Required** | Array of architectures to build for. For more information see [Supported platforms for automatic updates](#supported-platforms-for-automatic-updates). |
-| `"darwin_deps"` | **Required** | Array of homebrew dependencies for Darwin builds. Explicitly pass `[]` for empty. Default: `["go", "pkg-config", "nlopt-static", "x264", "jpeg-turbo", "ffmpeg"]` |
-
-{{% /expand %}}
-
-{{< expand "Python module script examples" >}}
-
-The following code snippet demonstrates an example `setup.sh` for a Python module:
-
-```bash {class="line-numbers linkable-line-numbers"}
-#!/bin/sh
-cd `dirname $0`
-
-# Create a virtual environment to run our code
-VENV_NAME="venv"
-PYTHON="$VENV_NAME/bin/python"
-ENV_ERROR="This module requires Python >=3.8, pip, and virtualenv to be installed."
-
-if ! python3 -m venv $VENV_NAME >/dev/null 2>&1; then
-  echo "Failed to create virtualenv."
-  if command -v apt-get >/dev/null; then
-    echo "Detected Debian/Ubuntu, attempting to install python3-venv automatically."
-    SUDO="sudo"
-    if ! command -v $SUDO >/dev/null; then
-      SUDO=""
-    fi
-  if ! apt info python3-venv >/dev/null 2>&1; then
-    echo "Package info not found, trying apt update"
-    $SUDO apt -qq update >/dev/null
-  fi
-  $SUDO apt install -qqy python3-venv >/dev/null 2>&1
-  if ! python3 -m venv $VENV_NAME >/dev/null 2>&1; then
-    echo $ENV_ERROR >&2
-    exit 1
-  fi
-  else
-    echo $ENV_ERROR >&2
-    exit 1
-  fi
-fi
-
-# remove -U if viam-sdk should not be upgraded whenever possible
-# -qq suppresses extraneous output from pip
-echo "Virtualenv found/created. Installing/upgrading Python packages..."
-if ! [ -f .installed ]; then
-  if ! $PYTHON -m pip install -r requirements.txt -Uqq; then
-    exit 1
-  else
-    touch .installed
-  fi
-fi
-```
-
-The following code snippet demonstrates an example `build.sh` for a Python module:
-
-```bash {class="line-numbers linkable-line-numbers"}
-#!/bin/sh
-cd `dirname $0`
-
-# Create a virtual environment to run our code
-VENV_NAME="venv"
-PYTHON="$VENV_NAME/bin/python"
-
-if ! $PYTHON -m pip install pyinstaller -Uqq; then
-    exit 1
-fi
-
-$PYTHON -m PyInstaller --onefile --hidden-import="googleapiclient" src/main.py
-tar -czvf dist/archive.tar.gz ./dist/main
-```
-
-{{< /expand >}}
-
-You can test this build configuration by running the Viam CLI's [`build local` command](/cli/#using-the-build-subcommand) on your development machine:
-
-```sh {class="command-line" data-prompt="$"}
-viam module build local
-```
-
-The command will run your build instructions locally without running a cloud build job.
-
-For more details, see the [`build-action` GitHub Action documentation](https://github.com/viamrobotics/build-action), or take a look through one of the following example repositories that show how to package and deploy modules using the Viam SDKs:
-
-- [Golang CI yaml](https://github.com/viam-labs/wifi-sensor/blob/main/.github/workflows/build.yml)
-- [Golang Example CI meta.json](https://github.com/viam-labs/wifi-sensor/blob/main/meta.json)
-<!-- - [C++ Example CI yaml](https://github.com/viamrobotics/module-example-cpp/blob/main/.github/workflows/build2.yml)
-- [C++ Example CI meta.json](https://github.com/viamrobotics/module-example-cpp/blob/main/meta.json) -->
-
-  {{% /tab %}}
-  {{% tab name="upload-module" %}}
-
-  If you already have your own CI with access to arm runners or only intend to build on `x86` or `mac`, you can use the `upload-module` GitHub action instead which allows you to define the exact build steps.
-
-  Add this to your GitHub workflow:
-
-  ```yaml {class="line-numbers linkable-line-numbers"}
-  on:
-    push:
-    release:
-      types: [released]
-
-  jobs:
-    publish:
-      runs-on: ubuntu-latest
-      steps:
-        - uses: actions/checkout@v3
-        - name: build
-          run: echo "your build command goes here" && false # <-- replace this with the command that builds your module's tar.gz
-        - uses: viamrobotics/upload-module@v1
-          # if: github.event_name == 'release' # <-- once the action is working, uncomment this so you only upload on release
-          with:
-            module-path: module.tar.gz
-            platform: linux/amd64 # <-- replace with your target architecture, or your module will not deploy
-            version: ${{ github.event_name == 'release' && github.ref_name || format('0.0.0-{0}.{1}', github.ref_name, github.run_number) }} # <-- see 'Versioning' section below for explanation
-            key-id: ${{ secrets.viam_key_id }}
-            key-value: ${{ secrets.viam_key_value }}
-  ```
-
-Set `run` to the command you use to build and package your module, such as invoking a makefile or running a shell script.
-When you are ready to test the action, uncomment `if: github.event_name == 'release'` to enable the action to trigger a run when you [issue a release](https://docs.github.com/en/repositories/releasing-projects-on-github).
-
-For guidance on configuring the other parameters, see the documentation for each:
-
-- [`org-id`](/cli/#using-the---org-id-and---public-namespace-arguments): Not required if your module is public.
-- [`platform`](/cli/#using-the---platform-argument): You can only upload one platform at a time.
-- [`version`](https://github.com/viamrobotics/upload-module/blob/main/README.md#versioning): See [Using the --version argument](/cli/#using-the---version-argument) for more details on the types of versioning supported.
-
-For more details, see the [`upload-module` GitHub Action documentation](https://github.com/viamrobotics/upload-module), or take a look through one of the following example repositories that show how to package and deploy modules using the Viam SDKs:
-
-- [Python with virtualenv](https://github.com/viam-labs/python-example-module)
-- [Python with docker](https://github.com/viamrobotics/python-container-module)
-- [Golang](https://github.com/viam-labs/wifi-sensor)
-- [C++](https://github.com/viamrobotics/module-example-cpp)
-
-  {{% /tab %}}
-  {{< /tabs >}}
-
-3. [Create an organization API key](/cli/#create-an-organization-api-key) with owner role:
-
-   ```sh {class="command-line" data-prompt="$"}
-   viam organizations api-key create --org-id <org-id> --name <key-name>
-   ```
-
-1. Add the key ID and value as GitHub repository secrets named `viam_key_id` and `viam_key_value`.
-
-1. Create a [release](https://docs.github.com/en/repositories/releasing-projects-on-github) in GitHub to trigger the build.
-   The build can be quick or take over 15 minutes to complete, depending on factors including the size of the module.
-
-   Once the build is complete, the module will automatically update in the [registry](https://app.viam.com/registry), and the machines set to use the latest [version](/operate/modules/advanced/module-configuration/#module-versioning) of the module will automatically update to the new version.
-
-#### Supported platforms for automatic updates
-
-When using cloud build, you can specify which platforms you want to build your module for in the `arch` field of your `meta.json` file.
-The following table lists all available platforms:
-
-<!-- prettier-ignore -->
-| Platform | Supported in cloud build | Container used by cloud build | Notes |
-|----------|--------------------------|------------------------------|-------|
-| `linux/amd64` | ✅ | Ubuntu | Standard x86_64 Linux platform. |
-| `linux/arm64` | ✅ | Ubuntu | For ARM64 Linux devices like Raspberry Pi 4. |
-| `darwin/arm64` | ✅ | macOS | For Apple Silicon Macs (M1/M2/M3). |
-| `linux/arm32v6` | ❌ | N/A | For older ARM devices; must be built manually. |
-| `linux/arm32v7` | ❌ | N/A | For 32-bit ARM devices; must be built manually. |
-| `windows/amd64` | ⚠️ | N/A | <ul><li>Cloud builds work for Go modules but have issues linking to C libraries.</li><li>Windows support is still in development.</li></ul> |
-| `darwin/amd64` | ❌ | N/A | Intel Macs; must be built manually. You can choose to support it, though many modules do not since Apple is phasing out this platform. |
-
-{{% alert title="Note" color="note" %}}
-While the registry supports additional platforms like `windows/amd64`, `linux/arm32v6`, and `linux/arm32v7`, these are not currently supported by cloud build and must be [built and uploaded manually](#update-manually).
-{{% /alert %}}
-
-### Update manually
-
-Use the [Viam CLI](/cli/) to manually update your module:
-
-1. Edit your module code and update the [`meta.json`](/operate/modules/advanced/metajson/) file if needed.
-   For example, if you've changed the module's functionality, update the description in the `meta.json` file.
-
-2. For Python modules only, package your files as an archive, for example:
-
-   ```sh {class="command-line" data-prompt="$"}
-   tar -czf module.tar.gz run.sh requirements.txt src meta.json
-   ```
-
-   Supply the path to the resulting archive file in the next step.
-
-3. Upload to the Viam Registry:
-
-   ```sh {class="command-line" data-prompt="$"}
-   viam module upload --version <version> --platform <platform> <module-path>
-   ```
-
-   For example, `viam module upload --version 1.0.1 --platform darwin/arm64 my-module.tar.gz`.
-
-When you `upload` a module, the command performs basic [validation](/cli/#upload-validation) of your module to check for common errors.
-
-For more information, see the [`viam module` command](/cli/#module).
-
-## Change module visibility
-
-You can change the visibility of a module from public to private if:
-
-- you are an [owner](/manage/manage/rbac/) of the {{< glossary_tooltip term_id="organization" text="organization" >}} that owns the module, AND
-- no machines outside of the organization that owns the module have the module configured (no other orgs are using it).
-
-To change the visibility:
-
-1. Navigate to your module's page in the [registry](https://app.viam.com/registry).
-2. Hover to the right of the visibility indicator near the right side of the page until an **Edit** button appears, and click it to make changes.
-
-   {{<imgproc src="/registry/upload/edit-module-visibility.png" resize="x150" declaredimensions=true alt="A module page with a Visibility heading on the right side. Under it, an Edit button has appeared." class="shadow" >}}
-
-   The options are:
-
-   - **Private**: Only users inside your organization can view, use, and edit the module.
-   - **Public**: Any user inside or outside of your organization can view, use, and edit the module.
-   - **Unlisted**: Any user inside or outside of your organization, with a direct link, can view and use the module.
-     Only organization members can edit the module.
-     Not listed in the registry for users outside of your organization.
-
-You can also edit the visibility by editing the [meta.json](/operate/modules/advanced/metajson/) file and then running the following [CLI](/cli/#module) command:
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-viam module update
-```
-
-{{% hiddencontent %}}
-If you don't see a private module of yours in the registry, make sure that you have the correct organization selected in the upper right corner of the page.
-{{% /hiddencontent %}}
-
-## Edit the short description
-
-The short description is a brief summary of your module that appears in registry search results.
-You can edit it directly from the registry UI without updating your `meta.json` file.
-
-To edit the short description:
-
-1. Navigate to your module's page in the [registry](https://app.viam.com/registry).
-2. Click the edit icon next to the short description field.
-3. Enter the new description and save your changes.
-
-## Delete a module
-
-You can delete a module if:
-
-- you are an [owner](/manage/manage/rbac/) in the {{< glossary_tooltip term_id="organization" text="organization" >}} that owns the module, AND
-- no machines have the module configured.
-
-To delete a module:
-
-1. Navigate to its page in the [registry](https://app.viam.com/registry).
-2. Click the **...** menu in the upper-right corner of the page, and click **Delete**.
-
-   {{<imgproc src="/registry/upload/delete-module.png" resize="x200" declaredimensions=true alt="A module page with the ... menu open. Delete is the only option in the menu." class="shadow" >}}
-
-{{% alert title="Note" color="note" %}}
-
-If you need to delete a module and the delete option is unavailable to you, please [contact our support team](mailto:contact@viam.com) for assistance.
-
-{{% /alert %}}
-
-{{% hiddencontent %}}
-Other registry items such as training scripts and ML models can be deleted in the same way as modules.
-{{% /hiddencontent %}}
-
-### Delete just one version of a module
-
-Deleting a version of a module requires the same org owner permissions as deleting the entire module, and similarly, you cannot delete a version if any machines are using it.
-To delete just one version of a module:
-
-1. Navigate to its page in the [registry](https://app.viam.com/registry).
-
-1. Click **Show previous versions** under the **Latest version** heading.
-
-1. Hover on the architecture pill next to the version you'd like to delete and click the trash icon.
-
-You cannot upload a new file with the same version number as the deleted one.
-To upload another version, you must increment the version number to a later version number.
-
-## Transfer ownership of a module
-
-To transfer ownership of a module from one organization to another:
-
-1. You must be an [owner](/manage/manage/rbac/) in both the current and new organizations.
-
-1. Navigate to the module's page in the [registry](https://app.viam.com/registry).
-
-1. Make sure the visibility of the module is set to **Public**.
-
-1. Click the **...** menu in the upper-right corner of the page, and click **Transfer ownership**.
-
-1. Select the new organization from the dropdown menu, then click **Transfer module**.
-
-1. (Recommended) Transfer the GitHub repository containing the module code to the new owner.
-   Be sure to remove the existing secrets from the repository's settings before transferring.
-   If the repository is using Viam's cloud build, the secrets contain an organization API key that will be exposed to the new owner after the repository transfer.
-
-1. Update the `meta.json` file to reflect the new organization:
-
-   - Change the first part of the `module_id` field to the new organization's [namespace](/operate/modules/advanced/metajson/#create-a-namespace-for-your-organization).
-   - For each model, change the first part of the `model` field to the new organization's namespace.
-   - Update the `url` field to point to the new code repository if it has moved.
-
-1. Update the module code:
-
-   - Throughout your module implementation code, change the model names in your component or service classes to match the changes you made to the `meta.json` file.
-
-1. Publish a new version of the module to the registry by following either set of update steps on this page.
-   This ensures that the model names in the module code match the registered model names in the registry.
-
-1. (Recommended) Update the `model` field in the configuration of any machines that use the module to use the new organization's namespace.
-   Viam maintains backwards compatibility with the old namespace, but you should update the configuration to use the new namespace to avoid confusion.
-
-## Rename a module
-
-You can rename a module that your organization owns through the Viam web interface.
-To rename a module:
-
-1. Navigate to your module page at `app.viam.com/module/<namespace>/<module-name>`.
-1. Click the **...** menu in the top right corner of the module page.
-1. Select **Rename** from the dropdown menu.
-1. Enter the new module name in the modal that appears.
-1. Click **Rename** to confirm the change.
-
-When you rename a module, Viam reserves the old module name for backwards compatibility and you cannot reuse it.
-
-Existing machine configurations containing the old module name will continue to work.
-
-{{% hiddencontent %}}
-
-## Rename a model
-
-If you need to change the name of a model that a module implements, do the following:
-
-1. Update the `model` field in the `meta.json` file to the new model name.
-
-1. Update the model name in the module code to match the new model name.
-
-1. Publish a new version of the module to the registry by following either set of update steps on this page.
-
-1. (Recommended) Update the configuration of any machines that use the module to use the new model name.
-   Viam maintains backwards compatibility with the old model name, but updating the configuration is recommended to avoid confusion.
-
-{{% /hiddencontent %}}
diff --git a/docs/operate/modules/advanced/metajson.md b/docs/operate/modules/advanced/metajson.md
deleted file mode 100644
index 29b61a0ad1..0000000000
--- a/docs/operate/modules/advanced/metajson.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: "meta.json reference"
-linkTitle: "meta.json reference"
-weight: 40
-layout: "docs"
-type: "docs"
-description: "Reference for the meta.json file, module naming, models, and applications."
-aliases:
-  - /operate/modules/create-module/metajson/
-  - /operate/reference/naming-modules/
-  - /operate/modules/other-hardware/naming-modules/
-  - /operate/modules/advanced/module-naming/
-date: "2025-11-11"
----
-
-The <file>meta.json</file> file is a JSON file that describes your {{< glossary_tooltip term_id="module" text="module" >}}.
-It contains information about the module, such as its name, version, and the resource {{< glossary_tooltip term_id="model" text="models" >}} it provides.
-
-The <file>meta.json</file> file has the following fields:
-
-{{< readfile "/static/include/metajson.md" >}}
-
-## Applications
-
-{{< readfile "/static/include/applications.md" >}}
-
-### Valid application identifiers
-
-If your module includes a [Viam application](/operate/control/viam-applications/), you need to define the application name in your module's [`meta.json`](/operate/modules/advanced/metajson/) file.
-Application names have the following requirements:
-
-- Application names must be all-lowercase.
-- Application names may only use alphanumeric (`a-z` and `0-9`) and hyphen (`-`) characters.
-- Application names may not start or end with a hyphen.
-- Application names must be unique within your organization's namespace.
-
-The URL for accessing your Viam app will contain your application name:
-
-```txt
-https://app-name_your-public-namespace.viamapps.com
-```
-
-For example, if your organization namespace is `acme` and your application name is `dashboard`, your application will be accessible at:
-
-```txt
-https://dashboard_acme.viamapps.com
-```
-
-## Create a namespace for your organization
-
-When uploading modules to the Viam Registry, you must set a unique namespace for your organization to associate your module with.
-
-To create a new namespace for your organization, click on the org's **Settings** in the top right of the navigation bar, then click the **Set a public namespace** button.
-Enter a name or use the suggested name for your namespace, and then click **Set namespace**.
-A namespace may only contain letters, numbers, and the dash (`-`) character.
-
-## Update a namespace for your organization
-
-You can change your organization's namespace on your organization settings page:
-
-1. Navigate to your organization settings page using the dropdown in the upper right corner of the web UI.
-1. Click the **Rename** button next to your current namespace.
-1. Enter the new namespace name in the field that appears.
-1. Click **Rename** to confirm the change.
-1. For each module your organization owns, update the module code and <file>meta.json</file> to reflect the new namespace.
-1. (Recommended) Update the `model` field in the configuration of any machines that use the module to use the new namespace.
-   Machine configurations that reference the old namespace will continue to work, but we recommend updating them to use the new namespace to avoid confusion.
-
-When you rename a namespace, Viam reserves the old namespace for backwards compatibility and you cannot reuse it.
diff --git a/docs/operate/modules/advanced/micro-module.md b/docs/operate/modules/advanced/micro-module.md
deleted file mode 100644
index c4a99f295e..0000000000
--- a/docs/operate/modules/advanced/micro-module.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: "Create modules for ESP32 microcontrollers"
-linkTitle: "Modules for ESP32"
-type: "docs"
-weight: 60
-images: ["/installation/thumbnails/esp32-espressif.png"]
-imageAlt: "E S P 32 - espressif"
-tags: ["modular resources", "components", "services", "registry"]
-description: "Create your own modules for use with an Espressif ESP32 microcontroller."
-languages: ["rust"]
-date: "2024-12-11"
-# updated: ""  # When the content was last entirely checked
-aliases:
-  - /installation/prepare/microcontrollers/development-setup/
-  - /get-started/installation/prepare/microcontrollers/development-setup/
-  - /get-started/installation/microcontrollers/development-setup/
-  - /get-started/installation/viam-micro-server-dev/
-  - /installation/viam-micro-server-dev/
-  - /operate/modules/other-hardware/micro-module/
----
-
-If no existing modules support your hardware or software, you can create your own.
-You'll write it in Rust and then embed it in the firmware you flash onto your device.
-
-## Create a new module for ESP32
-
-To create a new module compatible with the Micro-RDK, follow these steps:
-
-1. Set up your development environment following the [development setup instructions](/operate/install/setup-micro/#set-up-your-development-environment).
-
-1. Generate a new module skeleton from [this template](https://github.com/viamrobotics/micro-rdk/tree/main/templates/module):
-
-   ```sh { class="command-line" data-prompt="$"}
-   cargo generate --git https://github.com/viamrobotics/micro-rdk.git
-   ```
-
-   Select `templates/module` when prompted, give the module a name of your choice, and answer any additional prompts.
-
-   The CLI automatically initializes a git repository in the generated module directory.
-
-1. Navigate into the generated module directory:
-
-   ```sh { class="command-line" data-prompt="$"}
-   cd <path-to/your-module-directory>
-   ```
-
-1. Develop the module by defining structs which implement the necessary traits.
-   The required traits are determined by the API you chose to implement.
-
-   For example, to implement the sensor API, you need to implement `Readings`, `SensorT<f64>` and `Status` traits.
-
-   {{< expand "Example implementation" >}}
-   The following example <file>src/lib.rs</file> file implements the sensor API to return random numbers:
-
-   ```rust { class="line-numbers linkable-line-numbers" }
-    use std::sync::{Arc, Mutex};
-    use std::collections::HashMap;
-    use micro_rdk::DoCommand;
-    use micro_rdk::common::config::ConfigType;
-    use micro_rdk::common::registry::{ComponentRegistry, RegistryError, Dependency};
-    use micro_rdk::common::sensor::{
-        Sensor, SensorType, Readings, SensorError, SensorT, SensorResult,
-        GenericReadingsResult, TypedReadingsResult
-    };
-    use micro_rdk::common::status::{Status, StatusError};
-
-    pub fn register_models(registry: &mut ComponentRegistry) -> Result<(), RegistryError> {
-        registry.register_sensor("my_sensor", &MySensor::from_config)
-    }
-
-    #[derive(DoCommand)]
-    pub struct MySensor {}
-
-    impl MySensor {
-        pub fn from_config(_cfg: ConfigType, _deps: Vec<Dependency>) -> Result<SensorType, SensorError> {
-            Ok(Arc::new(Mutex::new(MySensor {})))
-        }
-    }
-
-    // Mark this type as a sensor
-    impl Sensor for MySensor {}
-
-    // Implementation for getting readings
-    impl SensorT<f64> for MySensor {
-        fn get_readings(&self) -> Result<TypedReadingsResult<f64>, SensorError> {
-            use rand::Rng;
-            let mut rng = rand::thread_rng();
-            let mut readings = HashMap::new();
-            readings.insert("random_value".to_string(), rng.gen());
-            Ok(readings)
-        }
-    }
-
-    // Required to convert typed readings to generic readings
-    impl Readings for MySensor {
-        fn get_generic_readings(&mut self) -> Result<GenericReadingsResult, SensorError> {
-            Ok(self
-                .get_readings()?
-                .into_iter()
-                .map(|v| (v.0, SensorResult::<f64> { value: v.1 }.into()))
-                .collect())
-        }
-    }
-
-    // Basic status implementation
-    impl Status for MySensor {
-        fn get_status(&self) -> Result<Option<micro_rdk::google::protobuf::Struct>, StatusError> {
-            Ok(Some(micro_rdk::google::protobuf::Struct {
-                fields: HashMap::new(),
-            }))
-        }
-    }
-
-   ```
-
-   {{< /expand >}}
-
-   For more examples, see the [example module implementation walkthrough](https://github.com/viamrobotics/micro-rdk/blob/main/examples/modular-drivers/README.md).
-
-## Test your module
-
-To use your module with your ESP32, follow the [Build and flash custom firmware](/operate/install/setup-micro/#build-and-flash-custom-firmware) workflow in a separate directory.
diff --git a/docs/operate/modules/advanced/module-configuration.md b/docs/operate/modules/advanced/module-configuration.md
deleted file mode 100644
index c364ff0499..0000000000
--- a/docs/operate/modules/advanced/module-configuration.md
+++ /dev/null
@@ -1,497 +0,0 @@
----
-title: "Modular resource and module configuration"
-linkTitle: "Module configuration"
-weight: 40
-type: docs
-icon: true
-description: "Configure module versions and module environment variables."
-aliases:
-  - /operate/reference/module-configuration/
-  - /operate/modules/other-hardware/module-configuration/
-date: "2025-11-11"
----
-
-This page contains detailed information on configuring modules and modular resources.
-For an introduction to configuring a module on your machine, see [Configure registry modules](/operate/modules/configure-modules/#configure-hardware-or-software-on-your-machine) instead.
-
-## Modular resource configuration details
-
-In the Viam web UI, when you add a modular resource, it adds two cards to the UI: a module card and a resource card.
-The modular resource card allows you to configure attributes for the resource.
-
-If you switch to **{} JSON** mode, you can also configure the attributes in JSON.
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-The resource card shows all configuration attributes for the resource.
-For example:
-
-{{<imgproc src="registry/modular-resources/ultrasonic-resource.png" resize="900x" style="width: 600px" declaredimensions=true alt="A configured modular resource example." class="shadow imgzoom" >}}
-
-{{% /tab %}}
-{{% tab name="JSON" %}}
-
-{{< tabs >}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "sensor-1",
-  "model": "viam:ultrasonic:sensor",
-  "api": "rdk:component:sensor",
-  "attributes": {
-    "trigger_pin": "13",
-    "echo_interrupt_pin": "15",
-    "board": "board-1",
-    "timeout_ms": 500
-  },
-  "depends_on": []
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-model-instance-name>",
-  "model": "<namespace>:<module-name>:<model-name>",
-  "api": "<model-API-namespace>:<component|service>:<model-name>",
-  "attributes": {
-    "<relevant attributes--see module Readme>"
-  },
-  "depends_on": []
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following properties are available for modular resources:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `attributes` | object | Sometimes **Required** | The configuration attributes for the resource model. Check the module's and model's Readme for information about available configuration attributes for a resource. |
-| `name` | string | **Required** | The name of the configured instance of the modular resource. The name can only contain letters, numbers, dashes, and underscores. Resource names must be unique across all {{< glossary_tooltip term_id="part" text="parts" >}} of a machine. In case of name collisions with resources from a remote, you can add a [`prefix` to the remote](/operate/reference/architecture/parts/#configure-a-remote-part). |
-| `api` | string | **Required** | The colon-delimited triplet `namespace:type:subtype` identifying the component or service API. Example: `rdk:component:motor`. See [valid API identifiers](#valid-api-identifiers) for more information. |
-| `model`| string | **Required** | A unique colon-delimited triplet `namespace:module-name:model-name` identifying the resource model. See [valid model identifiers](#valid-model-identifiers) for more information. |
-| `depends_on`| array | Optional | Deprecated. Use [dependencies](/operate/modules/advanced/dependencies/) instead. The names of resources that must be available before this resource starts. |
-| `notes` | string | Optional | Descriptive text to document the purpose, configuration details, or other important information about this modular resource. |
-
-### Valid API identifiers
-
-Each component or service API has a unique identifier in the form of a colon-delimited triplet, the {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet" >}}.
-
-The API namespace triplet is the same for all built-in and modular {{< glossary_tooltip term_id="model" text="models" >}} that implement a given API.
-For example, every motor model built into Viam, as well as every custom motor model provided by a module, all use the same API namespace triplet `rdk:component:motor` to indicate that they implement the [motor API](/operate/reference/components/motor/#api).
-
-The three pieces of the API namespace triplet are:
-
-{{< tabs >}}
-{{% tab name="Component" %}}
-
-- `namespace`: `rdk`
-- `type`: `component`
-- `api`: any one of [these component proto files](https://github.com/viamrobotics/api/tree/main/proto/viam/component), for example `motor` if you are creating a new motor model
-
-{{% /tab %}}
-{{% tab name="Service" %}}
-
-- `namespace`: `rdk`
-- `type`: `service`
-- `api`: any one of [these service proto files](https://github.com/viamrobotics/api/tree/main/proto/viam/service), for example `vision` if you are creating a new vision service model
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Valid model identifiers
-
-The {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet" >}} uniquely identifies a resource model.
-It uses the format: `namespace:module-name:model-name`, where:
-
-- `namespace` is the namespace of your organization, which you can find or [create](/operate/modules/advanced/metajson/#create-a-namespace-for-your-organization) on your organization settings page.
-
-  For example, if your organization uses the `acme` namespace, your models must all begin with `acme`, like `acme:module-name:mybase`.
-  If you do not intend to [upload your module](/operate/modules/deploy-a-module/) to the [registry](https://app.viam.com/registry), you do not need to use your organization's namespace as your model's namespace.
-
-  The `viam` namespace is reserved for models provided by Viam.
-
-- `module-name` is the name of your module.
-  Your `module-name` should describe the common functionality provided across the model or models provided by that module.
-  Many people also choose to use the module name as the name of the code repository (GitHub repo) that houses the module code.
-
-- `model-name` is the name of the new resource model that your module will provide.
-
-For example, if your organization namespace is `acme`, and you have written a new base implementation named `mybase` which you have implemented with a module named `my-custom-base-module`, you would use the namespace `acme:my-custom-base-module:mybase` for your model.
-
-Requirements:
-
-- Your model triplet must be all-lowercase.
-- Your model triplet may only use alphanumeric (`a-z` and `0-9`), hyphen (`-`), and underscore (`_`) characters.
-
-## Module configuration details
-
-In the Viam web UI, when you add a modular resource, it adds two cards to the UI: a module card and a resource card.
-The module card allows you to configure attributes for the module.
-
-If you switch to **{} JSON** mode, you can also configure the attributes in JSON.
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-The module card shows all configuration attributes for the module.
-For example:
-
-{{<imgproc src="registry/modular-resources/ultrasonic-module.png" resize="900x" style="width: 600px" declaredimensions=true alt="A configured module example." class="shadow imgzoom" >}}
-
-{{% /tab %}}
-{{% tab name="JSON" %}}
-
-Examples:
-
-```json {class="line-numbers linkable-line-numbers"}
-  "modules": [
-    {
-      "type": "registry",
-      "name": "viam_ultrasonic",
-      "module_id": "viam:ultrasonic",
-      "version": "0.0.2"
-    },
-    {
-      "type": "registry",
-      "name": "viam_tflite_cpu",
-      "module_id": "viam:tflite_cpu",
-      "version": "latest",
-      "disabled": true
-    },
-    {
-      "type": "registry",
-      "name": "viam_raspberry-pi",
-      "module_id": "viam:raspberry-pi",
-      "version": "1.1.0"
-    },
-    {
-      "type": "local",
-      "name": "local-module-1",
-      "executable_path": "/Users/jessamy/myFolderOfCode/my-control-logic/run.sh"
-    }
-  ]
-```
-
-The config of both a module and a corresponding modular resource resembles the following:
-
-{{< tabs >}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-model-instance-name>",
-      "model": "<module-namespace>:<module-name>:<model-name>",
-      "api": "<model-API-namespace>:<component|service>:<model-name>",
-      "attributes": {}
-    }
-  ],
-  "modules": [
-    {
-      "type": "registry",
-      "name": "<module-namespace>_<module-name>",
-      "module_id": "<module-namespace>:<module-name>",
-      "version": "<module-version>",
-      "env": {
-        "MY_VAR": "<some-value>",
-        "PATH": "<example-folder>:${environment.PATH}"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-The following is an example configuration for the [Intel Realsense module](https://app.viam.com/module/viam/realsense).
-The configuration adds `viam:camera:realsense` as a modular resource from the module `viam:realsense`.
-The model is configured as a component with the name `myRealsenseCamera1`.
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "myRealsenseCamera1",
-      "model": "viam:camera:realsense",
-      "api": "rdk:component:camera",
-      "attributes": {
-        "sensors": ["color", "depth"]
-      },
-      "depends_on": []
-    }
-  ],
-  "modules": [
-    {
-      "type": "registry",
-      "name": "viam_realsense",
-      "module_id": "viam:realsense",
-      "version": "0.0.11"
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% /tabs %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following properties are configurable for each module.
-
-<!--prettier-ignore-->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `type` | string | **Required** | `registry` or `local`, depending on whether the module is in the [registry](https://app.viam.com/registry) or is started [locally](/operate/modules/write-a-driver-module/#3-test-locally) on the device. |
-| `name` | string | **Required** | The name of the module. |
-| `module_id` | string | **Required** | The module ID, which includes either the module namespace or organization ID, followed by its name: `<namespace>:<module-name>` or `<org-id>:<module-name>`. The `module_id` uniquely identifies your module. Identical to the first two pieces of the {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet" >}}. |
-| `version` | string | **Required** | <p>You can specify: <ul><li>to use a specific version (X.Y.Z) of the module</li><li>to pin the module version to the latest version, so your machine automatically updates to the latest version of the module that is available, or to the latest patch release of a configured minor (X.Y.\_) or major (X.\_) version.</li></ul>For more information, see [Module versioning](/operate/modules/advanced/module-configuration/#module-versioning).</p> |
-| `env` | object | Optional | Environment variables available to the module. For example `{ "API_KEY": "${environment.API_KEY}" }`. Some modules require that you set environment variables as part of configuration. For more information, see [environment variables](#environment-variables). You can add and edit `env` by switching from **Builder** to **{} JSON** mode in the **CONFIGURE** tab. |
-| `executable_path` | string | Local modules only | The path to the module's executable file. Only applicable to, and required for, local modules. Registry modules use the `entrypoint` in the [<file>meta.json</file> file](/operate/modules/advanced/metajson/) instead. |
-| `disabled` | boolean | Optional | Whether to disable the module.<br>Default: `false`. |
-| `notes` | string | Optional | Descriptive text to document the purpose, configuration details, or other important information about this module. |
-| `log_level` | object | Optional | Set the log level for the module. See [Logging](/operate/reference/viam-server/#logging). |
-| `first_run_timeout` | number | Optional | The timeout duration for the first run script.<br>Default: `60m`. |
-| `tcp_mode` | boolean | Optional | Whether to start the module with a TCP connection. Regardless of the value set here, if the environment variable `VIAM_TCP_SOCKETS` is set to true, `viam-server` will start the module with a TCP connection.<br>TCP mode is currently only supported for Python and C++ modules.<br>Default: `false`. |
-
-### Module versioning
-
-You can configure how each module on your machine updates itself when a newer version becomes available from the Viam Registry.
-By default, a newly-added module is set to pin to the latest release (**Latest**) of the version you added.
-
-To change the update strategy for your module, set the **Pinned version type** for your module in its module card on the **CONFIGURE** tab.
-
-{{<imgproc src="registry/modular-resources/ultrasonic-module.png" resize="900x" style="width: 600px" declaredimensions=true alt="A configured module example." class="shadow imgzoom" >}}
-
-The following update options are available:
-
-- **Patch (X.Y.Z)**: Do not update to any other version.
-- **Minor (X.Y.\*)**: Only update to newer patch releases of the same minor release branch.
-  The module will automatically restart and update itself whenever new updates within the same minor release are available in the Viam Registry.
-  For example, use this option to permit a module with version `1.2.3` to update to version `1.2.4` or `1.2.5` but not `1.3.0` or `2.0.0`.
-- **Major (X.\*)**: Only update to newer patch and minor releases of the same major release branch.
-  The module will automatically restart and update itself whenever new updates within the same major release are available in the Viam Registry.
-  For example, use this option to permit a module with version `1.2.3` to update to version `1.2.4` or `1.3.0` but not `2.0.0` or `3.0.0`.
-- **Latest (`latest`)**: Always update to the latest version of this module available from the Viam Registry as soon as a new version becomes available.
-  This is the default.
-- **Latest with prerelease (`latest-with-prerelease`)**: Always update to the latest release or prerelease version of this module available from the Viam Registry as soon as the new version becomes available.
-
-When using the **Patch (X.Y.Z)** version type, you may select any patch version of the module from the **Version** dropdown menu, including past versions if desired.
-
-The current deployed version of your module and the latest version of that module available from the Viam Registry are shown on this module card for your reference.
-
-{{% alert title="Caution" color="caution" %}}
-For any version type other than **Patch (X.Y.Z)**, the module will upgrade as soon as an update that matches that specified version type is available, which will **restart the module**.
-If, for example, the module provides a motor component, and the motor is running, it will stop while the module upgrades.
-{{% /alert %}}
-
-If a module appears in both a {{< glossary_tooltip term_id="fragment" text="fragment" >}} and the part configuration, or in multiple fragments, Viam imports the newest of the configured versions.
-
-### Environment variables
-
-Each module has access to the following default environment variables.
-Not all of these variables are automatically available on [local modules](/operate/modules/write-a-driver-module/#3-test-locally); you can manually set variables your module requires if necessary.
-
-<!-- prettier-ignore -->
-| Name | Description | Automatically set on local modules? |
-| ---- | ----------- | ----------------------------------- |
-| `VIAM_HOME` | The root of the `viam-server` configuration.<br>Default for Linux, macOS, and WSL: <file>$HOME/.viam</file><br>Default for Windows: <file>C:\WINDOWS\system32\config\systemprofile\\.viam</file> | <p class="center-text"><i class="fas fa-check" title="yes"></i></p> |
-| `VIAM_MODULE_ROOT` | The root of the module install directory. The module process uses this directory as its current working directory (`cwd`). This variable is useful for file navigation that is relative to the root of the module.<br>Example: <file>/opt/my-module/verxxxx-my-module/</file> | <p class="center-text"><i class="fas fa-check" title="yes"></i></p> |
-| `VIAM_RESOURCE_CONFIGURATION_TIMEOUT` | Duration that resources are allowed to configure or reconfigure.<br>Example: `4m0s`<br>Default: `2m0s`. | <p class="center-text"><i class="fas fa-check" title="yes"></i></p> |
-| `VIAM_MODULE_STARTUP_TIMEOUT` | Duration that modules are allowed to start up.<br>Example: `7m15s`<br>Default: 5 minutes. | <p class="center-text"><i class="fas fa-check" title="yes"></i></p> |
-| `VIAM_MODULE_DATA` | A persistent folder location a module can use to store data across reboots and version updates. The folder will be removed when the module is removed from the machine, including when disabled in the machine configuration. This location is a good place to store [python virtual environments](/reference/sdks/python/python-venv/).<br>Example: <file>$VIAM_HOME/module-data/cloud-machine-id/my-module-name/</file> | <p class="center-text"><i class="fas fa-check" title="yes"></i></p> |
-| `VIAM_MODULE_ID` | The module ID of the module.<br>Example: `viam:realsense` | |
-| `VIAM_API_KEY` | An API key with access to the machine where this instance of the module is running. | <p class="center-text"><i class="fas fa-check" title="yes"></i></p> |
-| `VIAM_API_KEY_ID` | The ID of the API key with access to the machine where this instance of the module is running. | <p class="center-text"><i class="fas fa-check" title="yes"></i></p> |
-| `VIAM_MACHINE_PART_ID` | The ID of the part where this instance of the module is running. | |
-| `VIAM_MACHINE_ID` | The ID of the machine where this instance of the module is running. | |
-| `VIAM_MACHINE_FQDN` | The {{< glossary_tooltip term_id="machine-fqdn" text="fully qualified domain name" >}} of the machine where this instance of the module is running. | |
-| `VIAM_LOCATION_ID` | The ID of the {{< glossary_tooltip term_id="location" text="location" >}} that owns the machine where this instance of the module is running. | |
-| `VIAM_PRIMARY_ORG_ID` | The ID of the {{< glossary_tooltip term_id="organization" text="organization" >}} that owns the machine where this instance of the module is running. | |
-
-#### Set additional environment variables
-
-You can configure additional environment variables for your module, using your choice of variable name and value.
-For example, you could create a variable `MODULE_USER` with a string value:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "modules": [
-    {
-      ...
-      "env": {
-        "MODULE_USER": "my-username"
-      }
-    }
-  ]
-}
-```
-
-To access any system environment variable that `viam-server` has access to, use the notation `${environment.<ENV-VAR-NAME>}` where `<ENV-VAR-NAME>` represents a system environment variable, like `PATH`, `USER`, or `PWD`.
-For example, you can use `${environment.HOME}` to access the `HOME` environment variable for the user running `viam-server`:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "modules": [
-    {
-      ...
-      "env": {
-        "PATH": "/home/username/bin:${environment.PATH}"
-      }
-    }
-  ]
-}
-```
-
-#### Access environment variables from your module
-
-You can access module environment variables from within your module code in the same way you would access any other environment variables.
-For example, you could use the following Python code to access the `VIAM_HOME` variable:
-
-```python
-import os
-
-viam_home = os.environ.get("VIAM_HOME")
-```
-
-## Configure an unlisted module
-
-To configure a module that is uploaded to the Viam Registry but has [visibility](/operate/modules/advanced/manage-modules/#change-module-visibility) set to **Unlisted** (`public_unlisted`), you need to manually add the module to your configuration:
-
-{{% hiddencontent %}}
-A public unlisted module is the same as an unlisted module.
-{{% /hiddencontent %}}
-
-1. Navigate to the module's page in the Viam Registry, using the link to the module.
-
-1. Find the **Unlisted module usage** section.
-
-1. Copy the module configuration JSON snippet.
-
-1. Navigate to the **CONFIGURE** tab of the machine you want to configure.
-
-1. Switch to **JSON** mode.
-
-1. Paste the copied module configuration into your `modules` array.
-
-1. Copy the model configuration snippet for the model you want to use, and add it to your `components` or `services` array (as appropriate).
-   For example:
-
-   {{< tabs >}}
-   {{% tab name="Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-"components": [
-  {
-    "name": "sensor-1",
-    "api": "rdk:component:sensor",
-    "model": "jessamy:hello-world:hello-camera",
-    "attributes": {}
-  },
-  ...
-],
-"modules": [
-  {
-    "type": "registry",
-    "name": "hello-world",
-    "module_id": "jessamy:hello-world",
-    "version": "latest"
-  }
-]
-```
-
-{{% /tab %}}
-{{% tab name="Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-"<components|services>": [
-  {
-    "name": "<resource-name>",
-    "api": "<model-API-namespace>:<component|service>:<model-name>",
-    "model": "<module-namespace>:<module-name>:<model-name>",
-    "attributes": {}
-  }
-],
-"modules": [
-  {
-    "type": "registry",
-    "name": "<module-name>",
-    "module_id": "<module-namespace>:<module-name>",
-    "version": "latest"
-  }
-]
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Module meta.json configuration
-
-Each module must have a `meta.json` file that defines the module's properties. This file includes information about the module's ID, visibility, and other features.
-
-Example `meta.json` file:
-
-```json
-{
-  "module_id": "your-namespace:your-module",
-  "visibility": "public",
-  "url": "https://github.com/your-org/your-repo",
-  "description": "Your module description",
-  "entrypoint": "run.sh",
-  "first_run": "setup.sh",
-  "applications": [
-    {
-      "name": "your-app-name",
-      "type": "single_machine",
-      "entrypoint": "dist/index.html",
-      "fragmentIds": [],
-      "logoPath": "static/logo.png",
-      "customizations": {
-        "machinePicker": {
-          "heading": "Air monitoring dashboard",
-          "subheading": "Sign in and select your devices to view your air quality metrics in a dashboard."
-        }
-      }
-    }
-  ]
-}
-```
-
-<!-- prettier-ignore -->
-| Property     | Type   | Description |
-| ------------ | ------ | ----------- |
-| `module_id` | string | The module ID, which includes either the module namespace or organization ID, followed by its name: `<namespace>:<module-name>` or `<org-id>:<module-name>`. The `module_id` uniquely identifies your module. |
-| `visibility` | string | Whether the module is accessible only to members of your organization (`private`), visible to all Viam users (`public`), or unlisted (`public_unlisted`). |
-| `url` | string | The URL of the GitHub repository containing the source code of the module. Required for cloud build. Optional for local modules. |
-| `description` | string | The description of your module and what it provides. |
-| `models` | array | Deprecated. An array of objects describing the models provided by your module. Specified models are ignored. Models are inferred from the module itself. |
-| `entrypoint` | string | The name of the file that starts your module. This can be a compiled executable or a script. Required if you are shipping a model. |
-| `first_run` | string | The path to a script or binary that `viam-server` executes during the setup phase. It executes once when `viam-server` receives a new configuration, and only once per module or per version of the module. |
-
-For modules that include [Viam applications](/operate/control/viam-applications/), you can add the `applications` field.
-The `applications` field is an array of application objects with the following properties:
-
-<!-- prettier-ignore -->
-| Property     | Type   | Description |
-| ------------ | ------ | ----------- |
-| `name`       | string | The name of your application, which will be used in the URL (`name.publicnamespace.viamapps.com`) |
-| `type`       | string | The type of application: `"single_machine"` or `"multi_machine"`. Whether the application can access and operate one machine or multiple machines. |
-| `entrypoint` | string | The path to the HTML entry point for your application                                             |
-| `fragmentIds` | []string | Specify the fragment or fragments that a machine must contain to be selectable from the machine picker screen. Only for single machine applications. |
-| `logoPath` | string | The URL or the relative path to the logo to display on the machine picker screen for a single machine application. |
-| `customizations` | object | Override the branding heading and subheading to display on the authentication screen for single machine applications: <ul><li>`heading`: Override the heading. May not be longer than 60 characters. </li><li>`subheading`: Override the subheading. May not be longer than 256 characters.</li></ul> Example: `{ "heading": "Air monitoring dashboard", "subheading": "Sign in and select your devices to view your air quality metrics in a dashboard" }`. |
-
-For more information about Viam applications, see the [Viam applications documentation](/operate/control/viam-applications/).
diff --git a/docs/operate/modules/advanced/platform-apis.md b/docs/operate/modules/advanced/platform-apis.md
deleted file mode 100644
index 7a05866749..0000000000
--- a/docs/operate/modules/advanced/platform-apis.md
+++ /dev/null
@@ -1,310 +0,0 @@
----
-title: "Access platform APIs from within a module"
-linkTitle: "Use platform APIs"
-weight: 25
-layout: "docs"
-type: "docs"
-description: "Write your validate and reconfigure functions to handle dependencies in your custom modular resource."
-aliases:
-  - /operate/modules/create-module/platform-apis/
-date: "2025-11-05"
----
-
-To use the platform or machine APIs, you must authenticate using API keys.
-
-- [Use platform APIs from a module](#use-platform-apis-from-a-module)
-- [Use the machine management API from a module](#use-the-machine-management-api-from-a-module)
-
-## Use platform APIs from a module
-
-The following steps show you how to use the following APIs from a module:
-
-- [Fleet management (`app_client`)](/reference/apis/fleet/)
-- [Data client (`data_client`)](/reference/apis/data-client/)
-- [ML training (`ml_training_client`)](/reference/apis/ml-training-client/)
-- [Billing (`billing_client`)](/reference/apis/billing-client/)
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-1. Add the following imports:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   import os
-   from viam.app.viam_client import ViamClient
-   from viam.app.app_client import AppClient
-   from viam.app.data_client import DataClient
-   from viam.app.ml_training_client import MLTrainingClient
-   from viam.app.billing_client import BillingClient
-   ```
-
-1. Add the `viam_client` and other clients to the resource class:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   class TestSensor(Sensor, EasyResource):
-       viam_client: Optional[ViamClient] = None
-       app_client: Optional[AppClient] = None
-       data_client: Optional[DataClient] = None
-       ml_training_client: Optional[MLTrainingClient] = None
-       billing_client: Optional[BillingClient] = None
-
-       # ...
-   ```
-
-1. Initialize the clients and use them:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   async def some_module_function(self):
-      # Ensure there is only one viam_client connection
-      if not self.viam_client:
-          self.viam_client = await ViamClient.create_from_env_vars(dial_options)
-
-      self.app_client = self.viam_client.app_client
-      self.data_client = self.viam_client.data_client
-      self.ml_training_client = self.viam_client.ml_training_client
-      self.billing_client = self.viam_client.billing_client
-      # Use the clients in your module
-      locations = await self.app_client.list_locations(os.environ.get("VIAM_PRIMARY_ORG_ID"))
-   ```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-1. Add the following imports:
-
-   ```go {class="line-numbers linkable-line-numbers"}
-   "os"
-   "go.viam.com/rdk/app"
-   ```
-
-1. Add the `viam_client` and other clients to the resource class:
-
-   ```go {class="line-numbers linkable-line-numbers"}
-   type testPlatformApisGoModuleTestDataClient struct {
-     resource.AlwaysRebuild
-
-     name resource.Name
-
-     logger logging.Logger
-     cfg    *Config
-
-     cancelCtx  context.Context
-     cancelFunc func()
-
-     viamClient *app.ViamClient
-     appClient *app.AppClient
-     dataClient *app.DataClient
-     mlTrainingClient *app.MLTrainingClient
-     billingClient *app.BillingClient
-   }
-   ```
-
-1. Initialize the clients and use them:
-
-   ```go {class="line-numbers linkable-line-numbers"}
-   func (s *exampleModuleResource) SomeModuleFunction(ctx context.Context, extra map[string]interface{}) (error) {
-      if s.viamClient == nil {
-        var err error
-        s.viamClient, err = app.CreateViamClientFromEnvVars(ctx, &app.Options{}, s.logger)
-        if err != nil {
-          return nil, err
-        }
-        s.appClient = s.viamClient.AppClient()
-        s.dataClient = s.viamClient.DataClient()
-        s.mlTrainingClient = s.viamClient.MLTrainingClient()
-        s.billingClient = s.viamClient.BillingClient()
-      }
-      locations, err := s.appClient.ListLocations(ctx, os.Getenv("VIAM_PRIMARY_ORG_ID"))
-      if err != nil {
-        return nil, err
-      }
-
-      // ...
-
-   }
-   ```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Elevate access
-
-The [module environment variables](/operate/modules/advanced/module-configuration/) `VIAM_API_KEY` and `VIAM_API_KEY_ID` provide [machine owner access](/manage/manage/rbac/) for the machine the module is running on.
-
-If you need a higher level of access, you can pass API keys as part of the module configuration:
-
-1. Create an API key with the appropriate [permissions](/manage/manage/rbac/) from your organization settings page.
-1. Add the API key and API key ID values to the module configuration:
-
-   ```json
-   {
-     "modules": [
-       {
-         "type": "registry",
-         "name": "example-module",
-         "module_id": "naomi:example-module",
-         "version": "latest",
-         "env": {
-           "VIAM_API_KEY": "abcdefg987654321abcdefghi",
-           "VIAM_API_KEY_ID": "1234abcd-123a-987b-1234567890abc"
-         }
-       }
-     ]
-   }
-   ```
-
-   This changes the environment variables `VIAM_API_KEY` and `VIAM_API_KEY_ID` from the default to the provided ones.
-
-## Use the machine management API from a module
-
-To use the [machine management (`robot_client`) API](/reference/apis/robot/), you must get the machine's FQDN and API keys from the module environment variables.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-1. Add the following imports and the `create_robot_client_from_module` method:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   # Add imports
-   import os
-   from viam.robot.client import RobotClient
-
-   # For robot client, you can also use the machine's FQDN:
-   async def create_robot_client_from_module():
-       # Get API credentials from module environment variables
-       api_key = os.environ.get("VIAM_API_KEY")
-       api_key_id = os.environ.get("VIAM_API_KEY_ID")
-       machine_fqdn = os.environ.get("VIAM_MACHINE_FQDN")
-
-       if not api_key or not api_key_id or not machine_fqdn:
-           raise Exception("VIAM_API_KEY, VIAM_API_KEY_ID, and " +
-                           "VIAM_MACHINE_FQDN " +
-                           "environment variables are required")
-
-       # Create robot client options with API key authentication
-       opts = RobotClient.Options.with_api_key(
-           api_key=api_key,
-           api_key_id=api_key_id
-       )
-
-       # Create RobotClient using the machine's FQDN
-       robot_client = await RobotClient.at_address(machine_fqdn, opts)
-
-       return robot_client
-   ```
-
-1. Add the `robot_client` or other clients to the resource class:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   class TestSensor(Sensor, EasyResource):
-       robot_client: Optional[RobotClient] = None
-       # ...
-   ```
-
-1. Initialize the client and use it:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   async def some_module_function(self):
-       # Ensure there is only one robot client
-       if not self.robot_client:
-           self.robot_client = await create_robot_client_from_module()
-       # Use the robot client
-       resources = [str(name) for name in self.robot_client.resource_names]
-   ```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-1. Add the following imports and the `createRobotClientFromModule` function:
-
-   ```go {class="line-numbers linkable-line-numbers"}
-   "os"
-   "go.viam.com/rdk/robot/client"
-   "go.viam.com/utils/rpc"
-
-   func createRobotClientFromModule(ctx context.Context, logger logging.Logger) (*client.RobotClient, error) {
-     robotClient, err := client.New(
-           ctx,
-           os.Getenv("VIAM_MACHINE_FQDN"),
-           logger,
-           client.WithDialOptions(rpc.WithEntityCredentials(
-               os.Getenv("VIAM_API_KEY_ID"),
-               rpc.Credentials{
-                   Type:    rpc.CredentialsTypeAPIKey,
-                   Payload: os.Getenv("VIAM_API_KEY"),
-               })),
-       )
-       if err != nil {
-           return nil, err
-       }
-     return robotClient, nil
-   }
-   ```
-
-1. Add the `viam_client` and other clients to the resource class:
-
-   ```go {class="line-numbers linkable-line-numbers"}
-   type testPlatformApisGoModuleTestDataClient struct {
-     resource.AlwaysRebuild
-
-     name resource.Name
-
-     logger logging.Logger
-     cfg    *Config
-
-     cancelCtx  context.Context
-     cancelFunc func()
-
-     machine *client.RobotClient
-   }
-   ```
-
-1. Initialize the clients and use them:
-
-```go {class="line-numbers linkable-line-numbers"}
-func (s *exampleModuleResource) SomeModuleFunction(ctx context.Context, extra map[string]interface{}) (error) {
-  if s.machine == nil {
-    var err error
-    s.machine, err = createRobotClientFromModule(ctx, s.logger)
-    if err != nil {
-      return nil, err
-    }
-    defer s.machine.Close(context.Background())
-  }
-  resources := s.machine.ResourceNames()
-
-  // ...
-
-}
-```
-
-{{% /tab %}}
-{{% /tabs %}}
-
-### Elevate access
-
-The [module environment variables](/operate/modules/advanced/module-configuration/) `VIAM_API_KEY` and `VIAM_API_KEY_ID` provide [machine owner access](/manage/manage/rbac/) for the machine the module is running on.
-
-If you need a higher level of access to access other machines, you can pass API keys as part of the module configuration:
-
-1. Create an API key with the appropriate [permissions](/manage/manage/rbac/) from your organization settings page.
-1. Add the API key and API key ID values to the module configuration:
-
-   ```json
-   {
-     "modules": [
-       {
-         "type": "registry",
-         "name": "example-module",
-         "module_id": "naomi:example-module",
-         "version": "latest",
-         "env": {
-           "VIAM_API_KEY": "abcdefg987654321abcdefghi",
-           "VIAM_API_KEY_ID": "1234abcd-123a-987b-1234567890abc"
-         }
-       }
-     ]
-   }
-   ```
-
-   This changes the environment variables `VIAM_API_KEY` and `VIAM_API_KEY_ID` from the default to the provided ones.
diff --git a/docs/operate/modules/component-apis/_index.md b/docs/operate/modules/component-apis/_index.md
deleted file mode 100644
index 831f9008aa..0000000000
--- a/docs/operate/modules/component-apis/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-linkTitle: "Component APIs"
-title: "Component APIs"
-weight: 200
-layout: "empty"
-type: "docs"
-empty_node: true
----
diff --git a/docs/operate/modules/component-apis/arm.md b/docs/operate/modules/component-apis/arm.md
deleted file mode 100644
index c9d3582acb..0000000000
--- a/docs/operate/modules/component-apis/arm.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Arm Component"
-linkTitle: "Arm"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/arm/"
-aliases:
-  - /operate/modules/supported-hardware/arm/
----
diff --git a/docs/operate/modules/component-apis/base.md b/docs/operate/modules/component-apis/base.md
deleted file mode 100644
index cbcf29cec4..0000000000
--- a/docs/operate/modules/component-apis/base.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Base Component"
-linkTitle: "Base"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/base/"
-aliases:
-  - /operate/modules/supported-hardware/base/
----
diff --git a/docs/operate/modules/component-apis/board.md b/docs/operate/modules/component-apis/board.md
deleted file mode 100644
index 35ed931fa3..0000000000
--- a/docs/operate/modules/component-apis/board.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Board Component"
-linkTitle: "Board"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/board/"
-aliases:
-  - /operate/modules/supported-hardware/board/
----
diff --git a/docs/operate/modules/component-apis/button.md b/docs/operate/modules/component-apis/button.md
deleted file mode 100644
index 63c950eb83..0000000000
--- a/docs/operate/modules/component-apis/button.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Button Component"
-linkTitle: "Button"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/button/"
-aliases:
-  - /operate/modules/supported-hardware/button/
----
diff --git a/docs/operate/modules/component-apis/camera.md b/docs/operate/modules/component-apis/camera.md
deleted file mode 100644
index 7446851339..0000000000
--- a/docs/operate/modules/component-apis/camera.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Camera Component"
-linkTitle: "Camera"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/camera/"
-aliases:
-  - /operate/modules/supported-hardware/camera/
----
diff --git a/docs/operate/modules/component-apis/encoder.md b/docs/operate/modules/component-apis/encoder.md
deleted file mode 100644
index 60d2323ecd..0000000000
--- a/docs/operate/modules/component-apis/encoder.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Encoder Component"
-linkTitle: "Encoder"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/encoder/"
-aliases:
-  - /operate/modules/supported-hardware/encoder/
----
diff --git a/docs/operate/modules/component-apis/gantry.md b/docs/operate/modules/component-apis/gantry.md
deleted file mode 100644
index 4a1d1f90e2..0000000000
--- a/docs/operate/modules/component-apis/gantry.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Gantry Component"
-linkTitle: "Gantry"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/gantry/"
-aliases:
-  - /operate/modules/supported-hardware/gantry/
----
diff --git a/docs/operate/modules/component-apis/generic.md b/docs/operate/modules/component-apis/generic.md
deleted file mode 100644
index 0018d82b8e..0000000000
--- a/docs/operate/modules/component-apis/generic.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Generic Component"
-linkTitle: "Generic"
-weight: 20
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/generic/"
-aliases:
-  - /operate/modules/supported-hardware/generic/
----
diff --git a/docs/operate/modules/component-apis/gripper.md b/docs/operate/modules/component-apis/gripper.md
deleted file mode 100644
index 1321df3bad..0000000000
--- a/docs/operate/modules/component-apis/gripper.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Gripper Component"
-linkTitle: "Gripper"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/gripper/"
-aliases:
-  - /operate/modules/supported-hardware/gripper/
----
diff --git a/docs/operate/modules/component-apis/input-controller.md b/docs/operate/modules/component-apis/input-controller.md
deleted file mode 100644
index c7ba0ee7a5..0000000000
--- a/docs/operate/modules/component-apis/input-controller.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Input Controller Component"
-linkTitle: "Input Controller"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/input-controller/"
-aliases:
-  - /operate/modules/supported-hardware/input-controller/
----
diff --git a/docs/operate/modules/component-apis/motor.md b/docs/operate/modules/component-apis/motor.md
deleted file mode 100644
index 27a697bde0..0000000000
--- a/docs/operate/modules/component-apis/motor.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Motor Component"
-linkTitle: "Motor"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/motor/"
-aliases:
-  - /operate/modules/supported-hardware/motor/
----
diff --git a/docs/operate/modules/component-apis/movement-sensor.md b/docs/operate/modules/component-apis/movement-sensor.md
deleted file mode 100644
index 64890d2ccf..0000000000
--- a/docs/operate/modules/component-apis/movement-sensor.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Movement Sensor Component"
-linkTitle: "Movement Sensor"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/movement-sensor/"
-aliases:
-  - /operate/modules/orted-hardware/movement-sensor/
----
diff --git a/docs/operate/modules/component-apis/power-sensor.md b/docs/operate/modules/component-apis/power-sensor.md
deleted file mode 100644
index ccddcce2ea..0000000000
--- a/docs/operate/modules/component-apis/power-sensor.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Power Sensor Component"
-linkTitle: "Power Sensor"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/power-sensor/"
-aliases:
-  - /operate/modules/orted-hardware/power-sensor/
----
diff --git a/docs/operate/modules/component-apis/sensor.md b/docs/operate/modules/component-apis/sensor.md
deleted file mode 100644
index 8d2bef38eb..0000000000
--- a/docs/operate/modules/component-apis/sensor.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Sensor Component"
-linkTitle: "Sensor"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/sensor/"
-aliases:
-  - /operate/modules/supported-hardware/sensor/
----
diff --git a/docs/operate/modules/component-apis/servo.md b/docs/operate/modules/component-apis/servo.md
deleted file mode 100644
index 9cf4092219..0000000000
--- a/docs/operate/modules/component-apis/servo.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Servo Component"
-linkTitle: "Servo"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/servo/"
-aliases:
-  - /operate/modules/supported-hardware/servo/
----
diff --git a/docs/operate/modules/component-apis/switch.md b/docs/operate/modules/component-apis/switch.md
deleted file mode 100644
index 08d4611408..0000000000
--- a/docs/operate/modules/component-apis/switch.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Switch Component"
-linkTitle: "Switch"
-weight: 10
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/components/switch/"
-aliases:
-  - /operate/modules/supported-hardware/switch/
----
diff --git a/docs/operate/modules/configure-modules.md b/docs/operate/modules/configure-modules.md
deleted file mode 100644
index 4541debde6..0000000000
--- a/docs/operate/modules/configure-modules.md
+++ /dev/null
@@ -1,291 +0,0 @@
----
-linkTitle: "Use registry modules"
-title: "Configure registry modules"
-weight: 10
-layout: "docs"
-type: "docs"
-imageAlt: "Configure a Machine"
-images: ["/viam.svg"]
-description: "Use modules from the registry and their contained hardware components and software services on your machine."
-modulescript: true
-aliases:
-  - /program/extend/modular-resources/configure/
-  - /extend/modular-resources/configure/
-  - /modular-resources/configure/
-  - /registry/configure/
-  - /registry/modular-resources/
-  - /configure/
-  - /manage/configuration/
-  - /build/configure/
-  - /registry/
-  - /registry/program/extend/modular-resources/configure/
-  - /how-tos/use-cases/configure/
-  - /use-cases/configure/
-  - /operate/get-started/supported-hardware/
-  - /operate/modules/supported-hardware/
-date: "2025-11-04"
----
-
-Viam has a registry of {{< glossary_tooltip term_id="module" text="modules" >}} that implement [standardized APIs](/reference/apis/#component-apis) for categories of hardware {{< glossary_tooltip term_id="component" text="components" >}} and software {{< glossary_tooltip term_id="service" text="services" >}}.
-
-If you are using an ESP32 microcontroller, see the [ESP32-specific instructions](/operate/install/setup-micro/#configure-and-test-your-machine) for how to add modules to the firmware build.
-
-## About the Viam Registry of supported hardware and software
-
-The [registry](https://app.viam.com/registry?type=Module) is the storage and distribution system for {{< glossary_tooltip term_id="module" text="modules" >}}.
-Each module can contain any number of {{< glossary_tooltip term_id="resource" text="resources" >}}: components which wrap hardware drivers or services which implement software like ML models.
-
-There are also modules in the registry that do not directly drive any physical hardware, but rather augment physical hardware with another layer of abstraction, or add software functionality such as a chatbot integration.
-
-Some components and services are built into `viam-server`, so you won't find them in the registry.
-
-You can browse all built-in and modular registry components below or on your machine's configuration page.
-
-## Configure hardware or software on your machine
-
-**Prerequisite:** A machine with [`viam-server` installed and connected to the cloud](/operate/install/setup/) and with any hardware physically connected to your machine and powered on.
-
-1. Navigate to your machine's page.
-1. Click the **+** button on your machine's **CONFIGURE** tab.
-
-   {{<imgproc src="/get-started/plus-button.png" alt="Create a resource button." resize="600x" style="width:350px" class="imgzoom shadow">}}
-
-1. Click **Component or service**.
-   This opens a search menu for all existing hardware and software drivers.
-   Search for and select a _{{< glossary_tooltip term_id="model" text="model" >}}_ that supports your hardware or implements your software.
-   For hardware, search by name, model number, or manufacturer name.
-   Or try searching by broader category, for example "webcam" or "motor," since some components do not require drivers that are specific to their exact make and model.
-
-   {{<imgproc src="/get-started/component-search.png" alt="Component search results." resize="600x" style="width:260px" class="imgzoom shadow">}}
-
-   You can also browse available components in the [Browse supported hardware by component API](#browse-supported-hardware-by-component-api) section and services in the [Browse supported software by service API](#browse-supported-software-by-service-api) section.
-
-1. Follow the instructions in the configuration card to configure the model's attributes.
-
-   {{<imgproc src="/get-started/configuration-card.png" alt="Configure a component or service." resize="900x" style="width:450px" class="imgzoom shadow">}}
-
-   If you need more details, use the link to the module's README.
-
-1. Click the **TEST** panel of the component's configuration card to, for example, view your camera's stream, turn your motor, or see the latest readings from your sensor.
-
-   {{<imgproc src="/get-started/test-panel.png" alt="Sensor test panel showing readings." resize="900x" style="width:400px" class="imgzoom shadow">}}
-
-   If your resource is not working as expected, check the **ERROR LOGS** panel for error messages.
-   You can also [read more troubleshooting tips](/manage/troubleshoot/troubleshoot/) or get help from Viam's AI assistant by clicking on the **Ask AI** button.
-
-### How module configuration works
-
-When you add a modular resource _from the registry_, Viam automatically adds the module that provides it at the same time, generating a configuration card for the modular resource and a separate one for the module.
-If you add a built-in resource, Viam only adds a configuration card for the resource itself.
-
-For details on configuring versioning and environment variables for modules, see [Modular Resource and Module Configuration Details](/operate/modules/advanced/module-configuration/).
-
-{{< alert title="Tip: Organize resources into folders" color="tip" >}}
-
-If you have many components and services on one machine, you can add folders to your fragment and use them to organize the resources.
-
-{{< /alert >}}
-
-## Browse supported hardware by component API
-
-The following built-in and modular components are available for computers and SBCs running `viam-server`.
-Configure any of these components on your machine by following the steps in [Configure hardware or software on your machine](#configure-hardware-or-software-on-your-machine).
-
-If you don't find a component that supports your hardware, you can [create a new module](/operate/modules/write-a-driver-module/) to add it to the registry.
-
-{{< tabs >}}
-{{% tab name="All components" %}}
-
-{{<resources api="rdk:component" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Arm" %}}
-
-The following models implement the [arm component API](/reference/apis/components/arm/):
-
-{{<resources api="rdk:component:arm" type="arm" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Base" %}}
-
-The following models implement the [base component API](/reference/apis/components/base/):
-
-{{<resources api="rdk:component:base" type="base" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Board" %}}
-
-The following models implement the [board component API](/reference/apis/components/board/):
-
-{{<resources api="rdk:component:board" type="board" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Button" %}}
-
-The following models implement the [button component API](/reference/apis/components/button/):
-
-{{<resources api="rdk:component:button" type="button" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Camera" %}}
-
-The following models implement the [camera component API](/reference/apis/components/camera/):
-
-{{<resources api="rdk:component:camera" type="camera" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Encoder" %}}
-
-The following models implement the [encoder component API](/reference/apis/components/encoder/):
-
-{{<resources api="rdk:component:encoder" type="encoder" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Gantry" %}}
-
-The following models implement the [gantry component API](/reference/apis/components/gantry/):
-
-{{<resources api="rdk:component:gantry" type="gantry" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Generic" %}}
-
-The following models implement the [generic component API](/reference/apis/components/generic/):
-
-{{<resources api="rdk:component:generic" type="generic" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Gripper" %}}
-
-The following models implement the [gripper component API](/reference/apis/components/gripper/):
-
-{{<resources api="rdk:component:gripper" type="gripper" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Input Controller" %}}
-
-The following models implement the [input controller component API](/reference/apis/components/input-controller/):
-
-{{<resources api="rdk:component:input_controller" type="input_controller" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Motor" %}}
-
-The following models implement the [motor component API](/reference/apis/components/motor/):
-
-{{<resources api="rdk:component:motor" type="motor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Movement Sensor" %}}
-
-The following models implement the [movement sensor component API](/reference/apis/components/movement-sensor/):
-
-{{<resources api="rdk:component:movement_sensor" type="movement_sensor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Power Sensor" %}}
-
-The following models implement the [power sensor component API](/reference/apis/components/power-sensor/):
-
-{{<resources api="rdk:component:power_sensor" type="power_sensor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Sensor" %}}
-
-The following models implement the [sensor component API](/reference/apis/components/sensor/):
-
-{{<resources api="rdk:component:sensor" type="sensor" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Servo" %}}
-
-The following models implement the [servo component API](/reference/apis/components/servo/):
-
-{{<resources api="rdk:component:servo" type="servo" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Switch" %}}
-
-The following models implement the [switch component API](/reference/apis/components/switch/):
-
-{{<resources api="rdk:component:switch" type="switch" no-intro="true">}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% alert title="Support notice" color="note" %}}
-Modules in the list above are officially supported and maintained by Viam only if they are marked as "built-in," or if the first part of their model triplet is `viam`.
-{{% /alert %}}
-
-## Browse supported software by service API
-
-The following built-in and modular services are available for computers and SBCs running `viam-server`.
-Configure any of these services on your machine by following the steps in [Configure hardware or software on your machine](#configure-hardware-or-software-on-your-machine).
-
-If you don't find a service that supports your use case, you can [create a new module](/operate/modules/write-a-driver-module/) to add it to the registry.
-If you are looking to write control logic, see [Run control logic](/operate/modules/write-a-logic-module/) instead.
-
-{{< tabs >}}
-{{% tab name="All services" %}}
-
-{{<resources api="rdk:service" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Vision" %}}
-
-The following models implement the [vision service API](/reference/apis/services/vision/):
-
-{{<resources api="rdk:service:vision" type="vision" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="ML model" %}}
-
-The following models implement the [ML model service API](/reference/apis/services/ml/):
-
-{{<resources api="rdk:service:mlmodel" type="mlmodel" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Motion" %}}
-
-The following models implement the [motion service API](/reference/apis/services/motion/):
-
-{{<resources api="rdk:service:motion" type="motion" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Generic" %}}
-
-The following models implement the [generic service API](/reference/apis/services/generic/):
-
-{{<resources api="rdk:service:generic" type="generic" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="SLAM" %}}
-
-The following models implement the [SLAM service API](/reference/apis/services/slam/):
-
-{{<resources api="rdk:service:slam" type="slam" no-intro="true">}}
-
-{{% /tab %}}
-{{% tab name="Discovery" %}}
-
-The following models implement the [discovery service API](/reference/apis/services/discovery/):
-
-{{<resources api="rdk:service:discovery" type="discovery" no-intro="true">}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% alert title="Support notice" color="note" %}}
-Modules in the list above are officially supported and maintained by Viam only if they are marked as "built-in," or if the first part of their model triplet is `viam`.
-{{% /alert %}}
-
-## Next steps
-
-If you have other hardware or software you wish to use, continue to [Support additional hardware and software](/operate/modules/write-a-driver-module/).
-If you have configured all your hardware and software, you can do a variety of things with your machine:
-
-- [Deploy control logic to run directly on your machines](/operate/modules/write-a-logic-module/)
-- [Write an app](/operate/control/web-app/) to interact with your machines using any of the Viam SDKs
-- [Capture data from your machines](/data/capture-sync/capture-and-sync-data/)
-- [Create a dataset](/data-ai/train/create-dataset/) and [train an AI model](/train/train-a-model/)
-- [Share the configuration across multiple machines](/manage/fleet/reuse-configuration/)
diff --git a/docs/operate/modules/deploy-a-module.md b/docs/operate/modules/deploy-a-module.md
deleted file mode 100644
index e3668aaf97..0000000000
--- a/docs/operate/modules/deploy-a-module.md
+++ /dev/null
@@ -1,508 +0,0 @@
----
-linkTitle: "Deploy a Module"
-title: "Deploy a Module"
-weight: 30
-layout: "docs"
-type: "docs"
-description: "Package, upload, and distribute a module through the Viam registry."
-date: "2025-01-30"
-aliases:
-  - /build/development/deploy-a-module/
-  - /development/deploy-a-module/
-  - /operate/modules/deploy-module/
-  - /extend/modular-resources/upload/
-  - /modular-resources/upload/
-  - /registry/upload/
-  - /how-tos/upload-module/
----
-
-A module that only runs locally on your development machine is useful for testing
-but limits what you can do. Deploying through the Viam module registry lets you:
-
-- **Install on any machine** in your organization (or publicly) through the
-  Viam app -- no SSH or manual file copying.
-- **Update over the air** -- release a new version and machines pick it up
-  automatically within minutes.
-- **Target multiple platforms** -- cloud build compiles for every architecture
-  you need so you don't have to cross-compile locally.
-
-## Concepts
-
-### The module registry
-
-The Viam module registry is a package manager for modules. It stores versioned
-module packages and serves them to machines on demand. When you configure a
-module on a machine, `viam-server` downloads the correct version for the
-machine's platform (OS and architecture).
-
-Modules can be:
-
-- **Private** -- visible only to your organization.
-- **Public** -- visible to all Viam users.
-- **Unlisted** -- usable by anyone who knows the module ID, but not shown in
-  registry search results.
-
-### meta.json
-
-Every module has a `meta.json` file that describes it to the registry:
-
-- **module_id** -- unique identifier in the format `namespace:module-name`.
-- **visibility** -- `private` or `public`.
-- **description** -- a summary shown in the registry.
-- **models** -- the list of resource models this module provides.
-- **entrypoint** -- the command that starts the module.
-- **build** -- configuration for cloud builds.
-
-### Cloud build
-
-Cloud build uses GitHub Actions to compile your module for multiple platforms
-automatically. When you push a version tag (for example, `v0.1.0`), a workflow builds
-your module for each target architecture, packages it, and uploads it to the
-registry.
-
-### Versioning
-
-The registry uses semantic versioning. Machines can be configured to:
-
-- **Track the latest version** -- automatically update when a new version is
-  uploaded (default).
-- **Pin to a specific version** -- stay on a fixed version.
-
-## Steps
-
-### 1. Review meta.json
-
-The generator creates a `meta.json` file in your module directory. Open it and
-review each field:
-
-```json
-{
-  "module_id": "my-org:my-sensor-module",
-  "visibility": "private",
-  "url": "https://github.com/my-org/my-sensor-module",
-  "description": "A custom sensor module that reads temperature and humidity from an HTTP endpoint.",
-  "models": [
-    {
-      "api": "rdk:component:sensor",
-      "model": "my-org:my-sensor-module:my-sensor"
-    }
-  ],
-  "entrypoint": "run.sh",
-  "build": {
-    "setup": "./setup.sh",
-    "build": "./build.sh",
-    "path": "dist/archive.tar.gz",
-    "arch": ["linux/amd64", "linux/arm64"]
-  }
-}
-```
-
-| Field               | Required | Purpose                                                                                                                 |
-| ------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------- |
-| `$schema`           | No       | JSON Schema URL for editor validation. Set to `https://dl.viam.dev/module.schema.json`.                                 |
-| `module_id`         | Yes      | Unique ID in the registry. Format: `namespace:name`.                                                                    |
-| `visibility`        | Yes      | Who can see and install the module: `private`, `public`, or `public_unlisted`.                                          |
-| `url`               | No       | Link to the source code repository. Required for cloud builds.                                                          |
-| `description`       | Yes      | Shown in the registry UI and search results.                                                                            |
-| `models`            | Yes      | List of resource models the module provides. Each has `api`, `model`, and optionally `description` and `markdown_link`. |
-| `entrypoint`        | Yes      | The path to the command that starts the module inside the archive.                                                      |
-| `first_run`         | No       | Path to a setup script that runs once after first install (default timeout: 1 hour).                                    |
-| `markdown_link`     | No       | Path to a README file (or `README.md#section` anchor) used as the registry description.                                 |
-| `build.setup`       | No       | Script that installs build dependencies (runs once).                                                                    |
-| `build.build`       | No       | Script that compiles and packages the module.                                                                           |
-| `build.path`        | No       | Path to the packaged output archive (default: `module.tar.gz`).                                                         |
-| `build.arch`        | No       | Target platforms to build for (default: `["linux/amd64", "linux/arm64"]`).                                              |
-| `build.darwin_deps` | No       | Homebrew dependencies for macOS builds (for example, `["go", "pkg-config"]`).                                           |
-
-Visibility options:
-
-- **`private`** -- only your organization can see and use the module.
-- **`public`** -- all Viam users can see and use it. Requires your organization
-  to have a public namespace.
-- **`public_unlisted`** -- any user can use the module if they know the ID, but
-  it does not appear in registry search results.
-
-Common `api` values:
-
-- `rdk:component:sensor` for sensors
-- `rdk:component:camera` for cameras
-- `rdk:component:motor` for motors
-- `rdk:component:generic` for generic components
-- `rdk:service:vision` for vision services
-
-### 2. Review the generated build scripts
-
-The generator creates build and setup scripts for your module. Review them
-and customize if needed:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-| File       | Purpose                                              |
-| ---------- | ---------------------------------------------------- |
-| `setup.sh` | Installs Python dependencies from `requirements.txt` |
-| `build.sh` | Packages the module into a `.tar.gz` archive         |
-| `run.sh`   | Entrypoint script that starts the module             |
-
-If your module has additional build steps (for example, compiling native extensions),
-add them to `build.sh`.
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-| File       | Purpose                                                               |
-| ---------- | --------------------------------------------------------------------- |
-| `setup.sh` | Installs build dependencies (Go modules are typically self-contained) |
-| `build.sh` | Cross-compiles the binary and packages it into a `.tar.gz` archive    |
-| `Makefile` | Local build targets                                                   |
-
-The generated `build.sh` uses `GOOS` and `GOARCH` environment variables to
-cross-compile for the target platform. Cloud build sets these automatically.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Make sure all scripts are executable:
-
-```bash
-chmod +x setup.sh build.sh run.sh
-```
-
-### 3. Deploy with cloud build (recommended)
-
-Cloud build is the recommended way to deploy modules. It uses GitHub Actions to
-compile your module for every target platform automatically, so you don't need
-to cross-compile locally. This eliminates a common class of errors where a
-binary built for one architecture (for example, `linux/amd64`) is uploaded for a
-different one (for example, `linux/arm64`), resulting in exec format errors on the
-target machine.
-
-If this is your first time deploying this module, you need to create it in the registry before uploading:
-
-```bash
-viam module create --name <module-name> --public-namespace <your-namespace>
-```
-
-This registers the module ID so the registry knows about it. You only need to do this once, after that, builds and uploads will work.
-If you used viam module generate, this step may have been done for you automatically.
-
-The generator creates the workflow file at
-`.github/workflows/deploy.yml`. To use it:
-
-**Push your code to GitHub:**
-
-```bash
-cd my-sensor-module
-git init
-git add .
-git commit -m "Initial module code"
-git remote add origin https://github.com/my-org/my-sensor-module.git
-git push -u origin main
-```
-
-**Add Viam credentials as GitHub secrets:**
-
-1. In the [Viam app](https://app.viam.com), go to your organization's settings.
-2. Create an API key with organization-level access (or use an existing one).
-3. In your GitHub repository, go to **Settings > Secrets and variables >
-   Actions**.
-4. Add two secrets:
-   - `VIAM_KEY_ID` -- your API key ID
-   - `VIAM_KEY_VALUE` -- your API key
-
-**Tag a release to trigger the build:**
-
-```bash
-git tag v0.1.0
-git push origin v0.1.0
-```
-
-The GitHub Action runs automatically. Monitor progress in the **Actions** tab
-of your GitHub repository. When it completes, your module is in the registry
-and ready to install on any machine.
-
-You can also trigger a cloud build from the CLI:
-
-```bash
-viam module build start
-```
-
-{{< alert title="Non-main default branches" color="tip" >}}
-Cloud build expects your repository's default branch to be `main`. If your
-repository uses a different default branch (for example, `master`), use the `--ref`
-flag:
-
-```bash
-viam module build start --ref master
-```
-
-{{< /alert >}}
-
-### 4. Deploy manually (alternative)
-
-If you cannot use cloud build, you can build and upload from the command line.
-
-{{< alert title="You must build for the target platform" color="caution" >}}
-When you upload manually, the binary in your archive must already be compiled
-for the target machine's OS and architecture. If you build on an x86 laptop
-and upload for `linux/arm64` without cross-compiling, the module will fail
-with an exec format error on ARM machines (like Raspberry Pi).
-
-Cloud build handles this automatically. If you deploy manually, you must
-cross-compile yourself or build on a machine with the target architecture.
-{{< /alert >}}
-
-**Build locally:**
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```bash
-cd my-sensor-module
-bash build.sh
-```
-
-Python modules don't require cross-compilation since they run in an
-interpreter, but native dependencies (C extensions) may need to be built for
-the target platform.
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```bash
-cd my-sensor-module
-# Cross-compile for the target platform
-GOOS=linux GOARCH=arm64 go build -o dist/module cmd/module/main.go
-tar -czf dist/archive.tar.gz -C dist module
-```
-
-Set `GOARCH` to match your target machine: `amd64` for x86_64, `arm64` for
-ARM (Raspberry Pi 4, Jetson, etc.).
-
-{{% /tab %}}
-{{< /tabs >}}
-
-**Upload to the registry:**
-
-```bash
-viam module upload \
-    --version=0.1.0 \
-    --platform=linux/arm64 \
-    dist/archive.tar.gz
-```
-
-To support multiple platforms, cross-compile and upload once per platform:
-
-```bash
-# Build and upload for amd64
-GOOS=linux GOARCH=amd64 go build -o dist/module cmd/module/main.go
-tar -czf dist/archive.tar.gz -C dist module
-viam module upload --version=0.1.0 --platform=linux/amd64 dist/archive.tar.gz
-
-# Build and upload for arm64
-GOOS=linux GOARCH=arm64 go build -o dist/module cmd/module/main.go
-tar -czf dist/archive.tar.gz -C dist module
-viam module upload --version=0.1.0 --platform=linux/arm64 dist/archive.tar.gz
-```
-
-### 5. Configure the module on a machine
-
-Once your module is in the registry, any machine in your organization can use it.
-
-1. In the [Viam app](https://app.viam.com), navigate to your machine's
-   **CONFIGURE** tab.
-2. Click **+** and select **Configuration block**.
-3. Search for your module by name or browse the registry.
-4. Add the module and create a component (or service) instance.
-5. Name the component and configure the attributes your module expects:
-
-```json
-{
-  "source_url": "https://api.example.com/sensor/data"
-}
-```
-
-7. Click **Save**.
-
-`viam-server` downloads the module from the registry, starts it, and makes the
-component available. Test it from the **CONTROL** tab.
-
-### 6. Manage versions
-
-**Release a new version:**
-
-```bash
-git add .
-git commit -m "Add humidity calibration offset"
-git tag v0.2.0
-git push origin main v0.2.0
-```
-
-If using cloud build, the workflow runs automatically. For manual upload:
-
-```bash
-viam module upload --version=0.2.0 --platform=linux/amd64 dist/archive.tar.gz
-```
-
-**Automatic updates:** By default, machines track the latest version. When you
-upload `v0.2.0`, all machines update automatically within a few minutes.
-
-**Pin to a specific version:**
-
-1. In the Viam app, go to the machine's **CONFIGURE** tab.
-2. Find the module in the configuration.
-3. Set the **Version** field to the specific version (for example, `0.1.0`).
-4. Click **Save**.
-
-**View module details:**
-
-You can view version history and details for your module in the
-[Viam registry](https://app.viam.com/registry).
-
-### 7. Keep meta.json in sync with your code
-
-As you add models to your module, you can auto-detect them from a built binary
-instead of editing `meta.json` by hand:
-
-```bash
-viam module update-models --binary ./bin/module
-```
-
-This inspects the binary, discovers registered models, and updates the `models`
-array in `meta.json`.
-
-Then push the updated metadata to the registry:
-
-```bash
-viam module update
-```
-
-### 8. Download a module
-
-To download a module from the registry (for testing or inspection):
-
-```bash
-viam module download --id my-org:my-sensor-module --version 0.1.0 --platform linux/amd64 --destination ./downloaded-module
-```
-
-### Platform constraints
-
-When uploading, you can attach platform constraint tags that restrict which
-machines can use a particular upload. For example, to require Debian:
-
-```bash
-viam module upload \
-    --version=0.1.0 \
-    --platform=linux/amd64 \
-    --tags=distro:debian \
-    dist/archive.tar.gz
-```
-
-The machine must report matching platform tags for the constrained upload to be
-selected. If no constraints are specified, the upload is available to all
-machines on that platform.
-
-### Upload limits
-
-The registry enforces these size limits:
-
-| Limit                          | Value  |
-| ------------------------------ | ------ |
-| Compressed package (`.tar.gz`) | 50 GB  |
-| Decompressed contents          | 250 GB |
-| Single file within package     | 25 GB  |
-
-Before uploading, the CLI validates that:
-
-- The entrypoint executable exists in the archive
-- The entrypoint has execute permissions
-- No symlinks escape the archive boundaries
-
-Use `--force` to skip these checks (not recommended for production uploads).
-
-## Try It
-
-1. Review the generated `meta.json` and build scripts in your module directory.
-2. Push your code to GitHub and add the Viam API key secrets.
-3. Tag a release (`v0.1.0`) to trigger a cloud build.
-4. Navigate to a machine in the Viam app and add your module from the registry.
-5. Configure a component and set the required attributes.
-6. Open the **CONTROL** tab and verify the component works.
-7. Tag a new release (`v0.2.0`) and verify the machine picks it up
-   automatically within a few minutes.
-
-## Troubleshooting
-
-{{< expand "Upload fails with \"not authenticated\"" >}}
-
-- Log in to the Viam CLI: `viam login`.
-- If using an API key, verify it has organization-level access.
-- Check that `VIAM_KEY_ID` and `VIAM_KEY_VALUE` are set correctly in your GitHub
-  secrets (for cloud build).
-
-{{< /expand >}}
-
-{{< expand "Upload fails with \"invalid meta.json\"" >}}
-
-- Verify `meta.json` is valid JSON. Run `python -m json.tool meta.json` or
-  `jq . meta.json` to check.
-- Confirm the `module_id` matches the format `namespace:module-name`.
-- Ensure all model entries have both `api` and `model` fields.
-
-{{< /expand >}}
-
-{{< expand "Module not appearing in the registry" >}}
-
-- Check the module's visibility. If it is `private`, it only appears for users
-  in your organization.
-- Verify the upload completed successfully.
-- The module may take a minute to propagate. Refresh the page and try again.
-
-{{< /expand >}}
-
-{{< expand "Machine cannot find the module" >}}
-
-- Verify the module version supports the machine's platform. If your machine
-  runs `linux/arm64` but you only uploaded for `linux/amd64`, the machine
-  cannot use it.
-- Check the module version. If the machine is pinned to a nonexistent version,
-  it will fail.
-- Confirm the machine is online and connected to the cloud.
-
-{{< /expand >}}
-
-{{< expand "Cloud build fails in GitHub Actions" >}}
-
-- Check the Actions tab in your GitHub repository for the build log.
-- If your repository's default branch is not `main` (for example, it uses `master`),
-  use `viam module build start --ref master`. The cloud build system expects
-  `main` by default.
-- Verify your `setup.sh` and `build.sh` scripts work locally.
-- Confirm the `build.path` in `meta.json` matches the actual output location.
-- Ensure the GitHub secrets are set and not expired.
-
-{{< /expand >}}
-
-{{< expand "Exec format error on target machine" >}}
-
-This means the binary was compiled for the wrong architecture. For example,
-you built on an x86 laptop but the target machine is ARM (Raspberry Pi).
-
-- Use [cloud build](#3-deploy-with-cloud-build-recommended) to compile for all
-  target platforms automatically.
-- If deploying manually, cross-compile with the correct `GOOS` and `GOARCH`
-  before uploading. See [Deploy manually](#4-deploy-manually-alternative).
-- Verify the platform flag in your `upload` command matches the binary's
-  architecture (for example, `--platform=linux/arm64` for Raspberry Pi 4).
-
-{{< /expand >}}
-
-{{< expand "Module works locally but fails after deployment" >}}
-
-- Check for hard-coded paths, missing environment variables, or dependencies
-  installed on your machine but not in the build environment.
-- For Python, verify all dependencies are in `requirements.txt`.
-- For Go, verify the binary is compiled for the correct target architecture.
-- Check the module logs in the **LOGS** tab.
-
-{{< /expand >}}
diff --git a/docs/operate/modules/lifecycle-of-a-module.md b/docs/operate/modules/lifecycle-of-a-module.md
deleted file mode 100644
index 7481a91e58..0000000000
--- a/docs/operate/modules/lifecycle-of-a-module.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: "Lifecycle of a module"
-linkTitle: "Lifecycle of a module"
-weight: 35
-layout: "docs"
-type: "docs"
-description: "Learn about the lifecycle of a module: How and when it starts, shuts down, and reconfigures."
-date: "2025-10-17"
-aliases:
-  - /operate/modules/other-hardware/lifecycle-module/
-  - /operate/modules/lifecycle-module/
----
-
-Modules run on your machine, alongside `viam-server` as separate processes, communicating with `viam-server` over UNIX sockets.
-
-[`viam-server` manages](/operate/reference/viam-server/) the dependencies, start-up, reconfiguration, [data management](/data/capture-sync/capture-and-sync-data/), and shutdown behavior of your {{< glossary_tooltip term_id="resource" text="modular resources" >}}.
-
-The lifecycle of a module and the resources it provides are as follows:
-
-1. `viam-server` starts, and if it is connected to the internet, it checks for configuration updates.
-
-1. `viam-server` starts any configured modules.
-
-1. When a module initializes, it registers its model or models and associated [APIs](/reference/apis/) with `viam-server`, making the models available for use.
-
-1. For each modular resource configured on the machine, `viam-server` uses the return values of the resource's `validate_config` function to determine the required and optional [dependencies](/operate/modules/advanced/dependencies/) of the resource.
-
-1. If a required dependency is not already running, `viam-server` starts it before starting the resource.
-   If a required dependency is not found or fails to start, `viam-server` does not start the resource that depends on it.
-
-1. `viam-server` calls the resource's constructor to build the resource based on its configuration.
-   Typically, the constructor calls the `reconfigure` function.
-
-1. Modular resources can fail to start for various reasons:
-
-   - a validation error or exception thrown in constructor
-   - a validation error or exception thrown during reconfiguration
-   - exceeding the [configured timeout limits](/operate/modules/advanced/module-configuration/#environment-variables) (default 5 minutes to start up and 1 minute to reconfigure)
-
-   Check the `viam-server` logs for these [errors](/monitor/troubleshoot/#timed-out-waiting-for-module) on the machine's **LOGS** tab.
-
-1. Once the modular resource has started up and finished configuring, it is available for use.
-
-1. If at any point the user changes the configuration of the machine, `viam-server` reconfigures the affected resources within 15 seconds.
-
-1. If `viam-server` attempts to shut down an individual module (for example due to a user disabling a module) and the module does not shut down within 30 seconds, `viam-server` kills the module process.
-
-1. When `viam-server` shuts down, it first attempts to shut down each module process sequentially in no particular order.
-   If a module process does not shut down within 30 seconds, it is killed with a `SIGKILL` signal.
-   If any modules are still running after 90 seconds, `viam-server` kills them as well.
-   This means that if four modules are running and the first three each fail to shut down within 30 seconds each, the fourth is killed immediately at the 90 second mark.
-
-Microcontroller modules function differently and are embedded in the firmware you flash onto your device.
-For more information see [Modules for ESP32](/operate/modules/advanced/micro-module/).
diff --git a/docs/operate/modules/write-a-driver-module/_index.md b/docs/operate/modules/write-a-driver-module/_index.md
deleted file mode 100644
index df9693dc9a..0000000000
--- a/docs/operate/modules/write-a-driver-module/_index.md
+++ /dev/null
@@ -1,1062 +0,0 @@
----
-linkTitle: "Write a Driver Module"
-title: "Write a Hardware Driver Module"
-weight: 20
-layout: "docs"
-type: "docs"
-description: "Build a module that implements a resource API and runs as a separate process."
-date: "2025-01-30"
-aliases:
-  - /build/development/write-a-module/
-  - /development/write-a-module/
-  - /development/write-a-driver-module/
-  - /registry/create/
-  - /use-cases/create-module/
-  - /how-tos/create-module/
-  - /how-tos/sensor-module/
-  - /registry/advanced/iterative-development/
-  - /build/program/extend/modular-resources/
-  - /program/extend/modular-resources/
-  - /extend/
-  - /extend/modular-resources/
-  - /extend/modular-resources/create/
-  - /build/program/extend/modular-resources/key-concepts/
-  - /modular-resources/key-concepts/
-  - /modular-resources/
-  - /extend/modular-resources/examples/custom-arm/
-  - /modular-resources/examples/custom-arm/
-  - /registry/examples/custom-arm/
-  - /program/extend/modular-resources/examples/
-  - /extend/modular-resources/examples/
-  - /modular-resources/examples/
-  - /registry/examples/
-  - /operate/get-started/other-hardware/
-  - /operate/get-started/other-hardware/create-module/
-  - /operate/modules/other-hardware/create-module/
-  - /how-tos/hello-world-module/
-  - /operate/get-started/other-hardware/hello-world-module/
-  - /operate/modules/create-module/hello-world-module/
-  - /operate/modules/supported-hardware/hello-world-module/
-  - /operate/modules/support-hardware/
----
-
-You want to use hardware that Viam doesn't support out of the box. A driver
-module integrates it with the platform by implementing a standard resource API
-(sensor, camera, motor, or any other type). Once your hardware speaks a Viam
-API, data capture, TEST cards, the SDKs, and other platform features work
-with it automatically.
-
-A driver module runs as a separate process alongside `viam-server`. It has its
-own dependencies, can crash without affecting `viam-server`, and can be
-packaged and distributed through the Viam registry.
-
-## Concepts
-
-### Choosing a resource API
-
-Viam defines standard APIs for common resource types. Pick the API that best
-matches your hardware or service:
-
-| API               | Use when your hardware...                             | Key methods                        |
-| ----------------- | ----------------------------------------------------- | ---------------------------------- |
-| `sensor`          | Produces readings (temperature, distance, humidity)   | `GetReadings`                      |
-| `camera`          | Produces images or point clouds                       | `GetImages`, `GetPointCloud`       |
-| `motor`           | Drives rotational or linear motion                    | `SetPower`, `GoFor`, `Stop`        |
-| `servo`           | Moves to angular positions                            | `Move`, `GetPosition`              |
-| `board`           | Exposes GPIO pins, analog readers, digital interrupts | `GPIOPinByName`, `AnalogByName`    |
-| `encoder`         | Tracks position or rotation                           | `GetPosition`, `ResetPosition`     |
-| `movement_sensor` | Reports position, orientation, velocity               | `GetPosition`, `GetLinearVelocity` |
-| `generic`         | Does not fit any of the above                         | `DoCommand`                        |
-
-For the full list of component and service APIs, see
-[Resource APIs](/reference/apis/).
-
-Using the right API means data capture, TEST cards, and other platform
-features work with your component automatically.
-
-Every resource also has a `DoCommand` method. Use it for functionality that
-does not map to the standard API methods -- for example, a sensor that also has
-a calibration routine. `DoCommand` accepts and returns arbitrary key-value maps.
-
-### Module lifecycle
-
-Every module goes through a defined lifecycle:
-
-1. **Startup** -- `viam-server` launches the module as a separate process. The
-   module registers its models and opens a gRPC connection back to the server.
-2. **Validation** -- For each configured resource, `viam-server` calls the
-   model's config validation method to check attributes and declare
-   dependencies.
-3. **Creation** -- If validation passes, `viam-server` calls the model's
-   constructor with the resolved dependencies.
-4. **Reconfiguration** -- If the user changes the configuration, `viam-server`
-   calls the validation method again, then the reconfiguration method.
-5. **Shutdown** -- `viam-server` calls the resource's close method. Clean up
-   resources here.
-
-For more detail, see [Module Lifecycle](/operate/modules/lifecycle-of-a-module/).
-
-### Dependencies
-
-Dependencies let your resource use other resources on the same machine. You
-declare dependencies in your config validation method by returning the names of
-resources your module needs. `viam-server` resolves these, ensures the
-depended-on resources are ready, and passes them to your constructor.
-
-## Steps
-
-When writing a module, follow the steps outlined below. To illustrate each step we'll use a sensor module as a worked example. The same patterns
-apply to any resource type -- substitute the appropriate API and methods for
-your use case.
-
-### 1. Generate the module
-
-Run the Viam CLI generator:
-
-```bash
-viam module generate
-```
-
-| Prompt           | What to enter               | Why                              |
-| ---------------- | --------------------------- | -------------------------------- |
-| Module name      | `my-sensor-module`          | A short, descriptive name        |
-| Language         | `python` or `go`            | Your implementation language     |
-| Visibility       | `private`                   | Keep it private while developing |
-| Namespace        | Your organization namespace | Scopes the module to your org    |
-| Resource subtype | `sensor`                    | The resource API to implement    |
-| Model name       | `my-sensor`                 | The model name for your sensor   |
-| Register         | `yes`                       | Registers the module with Viam   |
-
-The generator creates a complete project with the following files:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-| File                           | Purpose                                       |
-| ------------------------------ | --------------------------------------------- |
-| `src/main.py`                  | Entry point -- starts the module server       |
-| `src/models/my_sensor.py`      | Resource class skeleton -- you will edit this |
-| `requirements.txt`             | Python dependencies                           |
-| `meta.json`                    | Module metadata for the registry              |
-| `setup.sh`                     | Installs dependencies into a virtualenv       |
-| `build.sh`                     | Packages the module for upload                |
-| `.github/workflows/deploy.yml` | CI workflow for cloud builds                  |
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-| File                           | Purpose                                                |
-| ------------------------------ | ------------------------------------------------------ |
-| `cmd/module/main.go`           | Entry point -- starts the module server                |
-| `my_sensor_module.go`          | Resource implementation skeleton -- you will edit this |
-| `go.mod`                       | Go module definition                                   |
-| `Makefile`                     | Build targets                                          |
-| `meta.json`                    | Module metadata for the registry                       |
-| `.github/workflows/deploy.yml` | CI workflow for cloud builds                           |
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 2. Implement the resource API
-
-Open the generated resource file. The generator creates a class (Python) or
-struct (Go) with stub methods. You need to make three changes:
-
-1. Define your config attributes.
-2. Add validation logic.
-3. Implement the API methods for your resource type.
-
-The following example builds a sensor that reads temperature and humidity from
-a custom HTTP API endpoint. Replace the HTTP call with whatever data source
-your sensor uses.
-
-#### Define your config attributes
-
-Config attributes are the fields a user sets when they configure your component
-in the Viam app. The generator creates an empty config; add a field for each
-attribute your module needs.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-In `src/models/my_sensor.py`, add instance attributes to your class. These will
-be set in the `reconfigure` method:
-
-```python
-class MySensor(Sensor, EasyResource):
-    MODEL: ClassVar[Model] = Model(
-        ModelFamily("my-org", "my-sensor-module"), "my-sensor"
-    )
-
-    # Add your config attributes as instance variables
-    source_url: str
-    poll_interval: float
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-In the generated `.go` file, find the empty `Config` struct and add fields.
-Each field needs a `json` tag that matches the attribute name users will set in
-their config JSON:
-
-```go
-type Config struct {
-    SourceURL    string  `json:"source_url"`
-    PollInterval float64 `json:"poll_interval"`
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-#### Add validation logic
-
-The generator creates an empty validation method. Add checks for required
-fields and return any [dependencies](#dependencies) your module needs.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-Find `validate_config` in your class and add validation:
-
-```python
-    @classmethod
-    def validate_config(
-        cls, config: ComponentConfig
-    ) -> Tuple[Sequence[str], Sequence[str]]:
-        fields = config.attributes.fields
-        if "source_url" not in fields:
-            raise Exception("source_url is required")
-        if not fields["source_url"].string_value.startswith("http"):
-            raise Exception("source_url must be an HTTP or HTTPS URL")
-        return [], []  # No required or optional dependencies
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Find the `Validate` method on your `Config` struct and add validation:
-
-```go
-func (cfg *Config) Validate(path string) ([]string, []string, error) {
-    if cfg.SourceURL == "" {
-        return nil, nil, fmt.Errorf("source_url is required")
-    }
-    return nil, nil, nil // No required or optional dependencies
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The validation method returns two lists: required dependencies and optional
-dependencies. For a standalone sensor with no dependencies, return empty lists.
-See [Step 5](#5-handle-dependencies) for modules that depend on other
-components.
-
-#### Implement the constructor and reconfigure method
-
-The constructor creates your resource and the reconfigure method updates it when
-the config changes. In Python, the typical pattern is for `new` to call
-`reconfigure` so the config-reading logic lives in one place.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-Update `new` and add a `reconfigure` method:
-
-```python
-    @classmethod
-    def new(cls, config: ComponentConfig,
-            dependencies: Mapping[ResourceName, ResourceBase]) -> Self:
-        sensor = cls(config.name)
-        sensor.reconfigure(config, dependencies)
-        return sensor
-
-    def reconfigure(self, config: ComponentConfig,
-                    dependencies: Mapping[ResourceName, ResourceBase]) -> None:
-        fields = config.attributes.fields
-        self.source_url = fields["source_url"].string_value
-        self.poll_interval = (
-            fields["poll_interval"].number_value
-            if "poll_interval" in fields
-            else 10.0
-        )
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Find the generated constructor function. Update it to read your config fields
-and initialize your struct:
-
-```go
-func newMySensor(
-    ctx context.Context,
-    deps resource.Dependencies,
-    conf resource.Config,
-    logger logging.Logger,
-) (sensor.Sensor, error) {
-    cfg, err := resource.NativeConfig[*Config](conf)
-    if err != nil {
-        return nil, err
-    }
-
-    timeout := time.Duration(cfg.PollInterval) * time.Second
-    if timeout == 0 {
-        timeout = 10 * time.Second
-    }
-
-    return &MySensor{
-        Named:     conf.ResourceName().AsNamed(),
-        logger:    logger,
-        sourceURL: cfg.SourceURL,
-        client:    &http.Client{Timeout: timeout},
-    }, nil
-}
-```
-
-You will also need to add fields to the generated struct for any state your
-module needs at runtime:
-
-```go
-type MySensor struct {
-    resource.Named
-    resource.AlwaysRebuild
-    logger    logging.Logger
-    sourceURL string
-    client    *http.Client
-}
-```
-
-The generated struct includes `resource.AlwaysRebuild`, which tells
-`viam-server` to destroy and re-create the resource on every config change.
-This is the simplest approach and works well for most modules. For in-place
-reconfiguration, see [Step 6](#6-handle-reconfiguration-optional).
-
-{{% /tab %}}
-{{< /tabs >}}
-
-#### Implement the API method
-
-For a sensor, the key method is `GetReadings`, which returns a map of reading
-names to values. This is the method that data capture calls and your application
-code queries.
-
-The generator creates a stub that returns an error. Replace it with your
-implementation:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-Add a `get_readings` method to your class. The return type is
-`Mapping[str, SensorReading]` (import `SensorReading` from `viam.utils`):
-
-```python
-    async def get_readings(
-        self,
-        *,
-        extra: Optional[Mapping[str, Any]] = None,
-        timeout: Optional[float] = None,
-        **kwargs,
-    ) -> Mapping[str, SensorReading]:
-        try:
-            response = requests.get(self.source_url, timeout=5)
-            response.raise_for_status()
-            data = response.json()
-            return {
-                "temperature": data["temp"],
-                "humidity": data["humidity"],
-            }
-        except requests.RequestException as e:
-            self.logger.error(f"Failed to read from {self.source_url}: {e}")
-            return {"error": str(e)}
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Find the `Readings` method stub and replace it:
-
-```go
-type sensorResponse struct {
-    Temp     float64 `json:"temp"`
-    Humidity float64 `json:"humidity"`
-}
-
-func (s *MySensor) Readings(
-    ctx context.Context,
-    extra map[string]interface{},
-) (map[string]interface{}, error) {
-    resp, err := s.client.Get(s.sourceURL)
-    if err != nil {
-        s.logger.CErrorw(ctx, "failed to read from source",
-            "url", s.sourceURL, "error", err)
-        return nil, fmt.Errorf("failed to read from %s: %w", s.sourceURL, err)
-    }
-    defer resp.Body.Close()
-
-    var data sensorResponse
-    if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
-        return nil, fmt.Errorf("failed to decode response: %w", err)
-    }
-
-    return map[string]interface{}{
-        "temperature": data.Temp,
-        "humidity":    data.Humidity,
-    }, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< expand "View the complete resource file" >}}
-
-For reference, here is the complete resource file after all the changes above.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-`src/models/my_sensor.py`:
-
-```python
-import requests
-from typing import Any, ClassVar, Mapping, Optional, Sequence, Self, Tuple
-
-from viam.components.sensor import Sensor
-from viam.proto.app.robot import ComponentConfig
-from viam.proto.common import ResourceName
-from viam.resource.base import ResourceBase
-from viam.resource.easy_resource import EasyResource
-from viam.resource.types import Model, ModelFamily
-from viam.utils import SensorReading
-
-
-class MySensor(Sensor, EasyResource):
-    """A custom sensor that reads from an HTTP endpoint."""
-
-    MODEL: ClassVar[Model] = Model(
-        ModelFamily("my-org", "my-sensor-module"), "my-sensor"
-    )
-
-    source_url: str
-    poll_interval: float
-
-    @classmethod
-    def new(cls, config: ComponentConfig,
-            dependencies: Mapping[ResourceName, ResourceBase]) -> Self:
-        sensor = cls(config.name)
-        sensor.reconfigure(config, dependencies)
-        return sensor
-
-    @classmethod
-    def validate_config(
-        cls, config: ComponentConfig
-    ) -> Tuple[Sequence[str], Sequence[str]]:
-        fields = config.attributes.fields
-        if "source_url" not in fields:
-            raise Exception("source_url is required")
-        if not fields["source_url"].string_value.startswith("http"):
-            raise Exception("source_url must be an HTTP or HTTPS URL")
-        return [], []
-
-    def reconfigure(self, config: ComponentConfig,
-                    dependencies: Mapping[ResourceName, ResourceBase]) -> None:
-        fields = config.attributes.fields
-        self.source_url = fields["source_url"].string_value
-        self.poll_interval = (
-            fields["poll_interval"].number_value
-            if "poll_interval" in fields
-            else 10.0
-        )
-
-    async def get_readings(
-        self,
-        *,
-        extra: Optional[Mapping[str, Any]] = None,
-        timeout: Optional[float] = None,
-        **kwargs,
-    ) -> Mapping[str, SensorReading]:
-        try:
-            response = requests.get(self.source_url, timeout=5)
-            response.raise_for_status()
-            data = response.json()
-            return {
-                "temperature": data["temp"],
-                "humidity": data["humidity"],
-            }
-        except requests.RequestException as e:
-            self.logger.error(f"Failed to read from {self.source_url}: {e}")
-            return {"error": str(e)}
-
-    async def close(self):
-        self.logger.info("Shutting down MySensor")
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-`my_sensor_module.go`:
-
-```go
-package mysensormodule
-
-import (
-    "context"
-    "encoding/json"
-    "fmt"
-    "net/http"
-    "time"
-
-    "go.viam.com/rdk/components/sensor"
-    "go.viam.com/rdk/logging"
-    "go.viam.com/rdk/resource"
-)
-
-var Model = resource.NewModel("my-org", "my-sensor-module", "my-sensor")
-
-type Config struct {
-    SourceURL    string  `json:"source_url"`
-    PollInterval float64 `json:"poll_interval"`
-}
-
-func (cfg *Config) Validate(path string) ([]string, []string, error) {
-    if cfg.SourceURL == "" {
-        return nil, nil, fmt.Errorf("source_url is required")
-    }
-    return nil, nil, nil
-}
-
-func init() {
-    resource.RegisterComponent(sensor.API, Model,
-        resource.Registration[sensor.Sensor, *Config]{
-            Constructor: newMySensor,
-        },
-    )
-}
-
-type MySensor struct {
-    resource.Named
-    resource.AlwaysRebuild
-    logger    logging.Logger
-    sourceURL string
-    client    *http.Client
-}
-
-func newMySensor(
-    ctx context.Context,
-    deps resource.Dependencies,
-    conf resource.Config,
-    logger logging.Logger,
-) (sensor.Sensor, error) {
-    cfg, err := resource.NativeConfig[*Config](conf)
-    if err != nil {
-        return nil, err
-    }
-
-    timeout := time.Duration(cfg.PollInterval) * time.Second
-    if timeout == 0 {
-        timeout = 10 * time.Second
-    }
-
-    return &MySensor{
-        Named:     conf.ResourceName().AsNamed(),
-        logger:    logger,
-        sourceURL: cfg.SourceURL,
-        client:    &http.Client{Timeout: timeout},
-    }, nil
-}
-
-type sensorResponse struct {
-    Temp     float64 `json:"temp"`
-    Humidity float64 `json:"humidity"`
-}
-
-func (s *MySensor) Readings(
-    ctx context.Context,
-    extra map[string]interface{},
-) (map[string]interface{}, error) {
-    resp, err := s.client.Get(s.sourceURL)
-    if err != nil {
-        s.logger.CErrorw(ctx, "failed to read from source",
-            "url", s.sourceURL, "error", err)
-        return nil, fmt.Errorf("failed to read from %s: %w", s.sourceURL, err)
-    }
-    defer resp.Body.Close()
-
-    var data sensorResponse
-    if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
-        return nil, fmt.Errorf("failed to decode response: %w", err)
-    }
-
-    return map[string]interface{}{
-        "temperature": data.Temp,
-        "humidity":    data.Humidity,
-    }, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< /expand >}}
-
-#### Understanding the entry point
-
-The generator also creates the entry point file that `viam-server` launches.
-You typically do not need to modify it.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-`src/main.py`:
-
-```python
-import asyncio
-from viam.module.module import Module
-from models.my_sensor import MySensor  # noqa: F401
-
-
-if __name__ == "__main__":
-    asyncio.run(Module.run_from_registry())
-```
-
-`run_from_registry()` automatically discovers all imported resource classes and
-registers them with `viam-server`. If you add more models to your module, import
-them here.
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-`cmd/module/main.go`:
-
-```go
-package main
-
-import (
-    mysensormodule "my-org/my-sensor-module"
-    "go.viam.com/rdk/components/sensor"
-    "go.viam.com/rdk/module"
-    "go.viam.com/rdk/resource"
-)
-
-func main() {
-    module.ModularMain(resource.APIModel{sensor.API, mysensormodule.Model})
-}
-```
-
-`ModularMain` handles socket parsing, signal handling, and graceful shutdown.
-The import of the resource package triggers its `init()` function, which calls
-`resource.RegisterComponent` to register the model. If you add more models,
-add more `resource.APIModel` entries to the `ModularMain` call.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 3. Test locally
-
-Configure the module on your machine and verify it works.
-
-**Configure as a local module:**
-
-1. In the [Viam app](https://app.viam.com), navigate to your machine's
-   **CONFIGURE** tab.
-2. Click **+**, select **Advanced**, then **Local module**.
-3. Set the **Executable path** to your module binary or script.
-4. Click **Create**.
-5. Click **+**, select **Advanced**, then **Local component**.
-6. Select your module, set the type and model, and configure attributes:
-
-   ```json
-   {
-     "source_url": "https://api.example.com/sensor/data"
-   }
-   ```
-
-7. Click **Save**.
-
-**Test using the TEST card:**
-
-1. Find your sensor component and expand the **TEST** section.
-2. Your temperature and humidity values appear automatically under
-   **GetReadings**.
-
-**Get a ready-to-run code sample:**
-
-The **CONNECT** tab on your machine's page in the Viam app provides generated
-code samples in Python and Go that connect to your machine and access all
-configured components. Use this as a starting point for application code that
-interacts with your module.
-
-**Rebuild and redeploy during development:**
-
-`viam-server` does not automatically detect changes to your module's source
-files or binary. After making changes, use the CLI to rebuild and redeploy:
-
-```bash
-# Build locally, transfer to machine, and restart the module
-viam module reload-local --part-id <machine-part-id>
-
-# Restart the module without rebuilding (e.g., after editing Python source)
-viam module restart --part-id <machine-part-id>
-```
-
-The `reload-local` command runs your build command from `meta.json`, transfers
-the artifact to the target machine, updates the machine config, and restarts
-the module. Use `--no-build` to skip the build step if you already built
-manually.
-
-### 4. Add logging
-
-Both the Python and Go SDKs provide a logger that writes to `viam-server`'s log
-stream, visible in the **LOGS** tab.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-self.logger.info("Sensor initialized with source URL: %s", self.source_url)
-self.logger.debug("Raw response from source: %s", data)
-self.logger.warning("Source returned unexpected field: %s", field_name)
-self.logger.error("Failed to connect to source: %s", error)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-s.logger.CInfof(ctx, "Sensor initialized with source URL: %s", s.sourceURL)
-s.logger.CDebugf(ctx, "Raw response from source: %v", data)
-s.logger.CWarnw(ctx, "Source returned unexpected field", "field", fieldName)
-s.logger.CErrorw(ctx, "Failed to connect to source", "error", err)
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Use `info` for significant events, `debug` for detailed data, `warning` for
-recoverable problems, and `error` for failures.
-
-### 5. Handle dependencies
-
-Many modules need access to other resources on the same machine. To use
-another resource, you need to do three things:
-
-1. **Declare the dependency** in your config validation method by returning the
-   resource name in the required (or optional) dependencies list.
-2. **Resolve the dependency** in your constructor or reconfigure method by
-   looking it up from the `dependencies` map that `viam-server` passes in.
-3. **Call methods on it** in your API implementation, just like any other
-   typed resource.
-
-The following example shows all three. It implements a sensor that depends on
-another sensor -- it reads Celsius temperature readings from the source sensor
-and converts them to Fahrenheit. Watch for the numbered comments in the code:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-class TempConverterSensor(Sensor, EasyResource):
-    MODEL: ClassVar[Model] = Model(
-        ModelFamily("my-org", "my-sensor-module"), "temp-converter"
-    )
-
-    source_sensor: Sensor
-
-    @classmethod
-    def validate_config(
-        cls, config: ComponentConfig
-    ) -> Tuple[Sequence[str], Sequence[str]]:
-        fields = config.attributes.fields
-        if "source_sensor" not in fields:
-            raise Exception("source_sensor is required")
-        source = fields["source_sensor"].string_value
-        # 1. Declare: return the source sensor name as a required dependency
-        return [source], []
-
-    def reconfigure(self, config: ComponentConfig,
-                    dependencies: Mapping[ResourceName, ResourceBase]) -> None:
-        source_name = config.attributes.fields["source_sensor"].string_value
-        # 2. Resolve: find the dependency in the map viam-server passes in
-        for name, dep in dependencies.items():
-            if name.name == source_name:
-                self.source_sensor = dep
-                break
-
-    async def get_readings(self, *, extra=None, timeout=None,
-                           **kwargs) -> Mapping[str, SensorReading]:
-        # 3. Use: call methods on the dependency like any typed resource
-        readings = await self.source_sensor.get_readings()
-        celsius = readings["temperature"]
-        return {"temperature_f": celsius * 9.0 / 5.0 + 32.0}
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-type ConverterConfig struct {
-    SourceSensor string `json:"source_sensor"`
-}
-
-func (cfg *ConverterConfig) Validate(path string) ([]string, []string, error) {
-    if cfg.SourceSensor == "" {
-        return nil, nil, fmt.Errorf("source_sensor is required")
-    }
-    // 1. Declare: return the source sensor name as a required dependency
-    return []string{cfg.SourceSensor}, nil, nil
-}
-
-type TempConverterSensor struct {
-    resource.Named
-    resource.AlwaysRebuild
-    logger logging.Logger
-    source sensor.Sensor
-}
-
-func newTempConverter(
-    ctx context.Context,
-    deps resource.Dependencies,
-    conf resource.Config,
-    logger logging.Logger,
-) (sensor.Sensor, error) {
-    cfg, err := resource.NativeConfig[*ConverterConfig](conf)
-    if err != nil {
-        return nil, err
-    }
-
-    // 2. Resolve: look up the dependency by name from the map viam-server passes in
-    src, err := sensor.FromProvider(deps, cfg.SourceSensor)
-    if err != nil {
-        return nil, fmt.Errorf("source sensor %q not found: %w",
-            cfg.SourceSensor, err)
-    }
-
-    return &TempConverterSensor{
-        Named:  conf.ResourceName().AsNamed(),
-        logger: logger,
-        source: src,
-    }, nil
-}
-
-func (s *TempConverterSensor) Readings(
-    ctx context.Context,
-    extra map[string]interface{},
-) (map[string]interface{}, error) {
-    // 3. Use: call methods on the dependency like any typed resource
-    readings, err := s.source.Readings(ctx, extra)
-    if err != nil {
-        return nil, fmt.Errorf("failed to read source sensor: %w", err)
-    }
-    celsius, ok := readings["temperature"].(float64)
-    if !ok {
-        return nil, fmt.Errorf("source sensor did not return a temperature reading")
-    }
-    return map[string]interface{}{
-        "temperature_f": celsius*9.0/5.0 + 32.0,
-    }, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 6. Handle reconfiguration (optional)
-
-When a user changes a resource's configuration, `viam-server` calls your
-reconfiguration method instead of destroying and re-creating the resource.
-This is faster and preserves internal state like open connections.
-
-The generated code uses `resource.AlwaysRebuild` (Go) by default, which
-tells `viam-server` to destroy and re-create the resource on every config
-change. This is the simplest approach and works well for most modules.
-
-For in-place reconfiguration, implement the reconfiguration method to update
-your resource's fields directly:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-Implement `reconfigure` to update your resource from the new config. This
-method is also typically called from `new` (see the example in Step 2):
-
-```python
-def reconfigure(self, config: ComponentConfig,
-                dependencies: Mapping[ResourceName, ResourceBase]) -> None:
-    fields = config.attributes.fields
-    self.source_url = fields["source_url"].string_value
-    self.poll_interval = (
-        fields["poll_interval"].number_value
-        if "poll_interval" in fields
-        else 10.0
-    )
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Remove `resource.AlwaysRebuild` from your struct and implement `Reconfigure`:
-
-```go
-type MySensor struct {
-    resource.Named
-    logger    logging.Logger
-    sourceURL string
-    client    *http.Client
-}
-
-func (s *MySensor) Reconfigure(ctx context.Context,
-    deps resource.Dependencies, conf resource.Config) error {
-    cfg, err := resource.NativeConfig[*Config](conf)
-    if err != nil {
-        return err
-    }
-    s.sourceURL = cfg.SourceURL
-    s.client.Timeout = time.Duration(cfg.PollInterval) * time.Second
-    return nil
-}
-```
-
-Go provides these helper traits as alternatives to writing a `Reconfigure`
-method. Embed one in your struct:
-
-| Trait                              | Behavior                                                                             |
-| ---------------------------------- | ------------------------------------------------------------------------------------ |
-| `resource.AlwaysRebuild`           | Resource is destroyed and re-created on every config change (the generated default). |
-| `resource.TriviallyReconfigurable` | Config changes are accepted silently with no action.                                 |
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 7. Use the module data directory
-
-Every module gets a persistent data directory at the path specified by the
-`VIAM_MODULE_DATA` environment variable. Use this for caches, databases, or
-any state that should survive module restarts.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-import os
-
-data_dir = os.environ.get("VIAM_MODULE_DATA", "/tmp")
-cache_path = os.path.join(data_dir, "readings_cache.json")
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-dataDir := os.Getenv("VIAM_MODULE_DATA")
-cachePath := filepath.Join(dataDir, "readings_cache.json")
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The directory is created automatically by `viam-server` at
-`$VIAM_HOME/module-data/<machine-id>/<module-name>/` (where `VIAM_HOME`
-defaults to `~/.viam`) and persists across module
-restarts and reconfigurations.
-
-## Try It
-
-1. Generate a sensor module using `viam module generate`.
-2. Open the generated resource file and implement your config validation and
-   `GetReadings` method.
-3. Configure the module on your machine as a local module.
-4. Expand the **TEST** section on your sensor. Verify readings appear
-   automatically under **GetReadings**.
-5. Enable data capture on the sensor. Wait one minute, then check the **DATA**
-   tab to confirm readings are flowing to the cloud.
-6. Add a new key to the readings map (for example, `"pressure": 1013.25`).
-   Rebuild and redeploy with `viam module reload-local`. Verify the new reading
-   appears on the TEST card.
-
-## Troubleshooting
-
-{{< expand "Module crashes on startup" >}}
-
-- Check the **LOGS** tab for the crash traceback. The most common cause is a
-  missing dependency -- a Python import not in `requirements.txt` or a Go
-  package not in `go.mod`.
-- For Python, verify the module runs outside of `viam-server`:
-  `python3 -m src.main` (from your module directory, with the virtualenv
-  activated).
-- For Go, verify the binary runs: `./bin/<your-module-name>` (the output path
-  is set in your `Makefile`).
-- Check that your entrypoint script has execute permissions: `chmod +x run.sh`.
-
-{{< /expand >}}
-
-{{< expand "Module times out on startup" >}}
-
-`viam-server` expects the module to respond to a ready check within about 15
-seconds of launch. If your module does heavy initialization (loading large
-files, connecting to slow services), it may time out.
-
-- Move slow initialization out of `init()` or model registration and into the
-  constructor instead, where it runs per-resource rather than blocking module
-  startup.
-- Check the **LOGS** tab for timeout errors.
-
-{{< /expand >}}
-
-{{< expand "Dependency not found" >}}
-
-- Confirm the dependency name returned by your config validation method matches
-  the resource name on the machine exactly (names are compared as strings, so
-  case and spelling must match).
-- Verify the depended-on resource exists and is configured correctly.
-- Check for circular dependencies -- if A depends on B and B depends on A,
-  both will fail to start. Check the **LOGS** tab for "circular dependency"
-  errors.
-
-{{< /expand >}}
-
-{{< expand "Readings returning None or nil" >}}
-
-- Add logging inside your `GetReadings` implementation to see what data your
-  source returns.
-- `GetReadings` must return a non-nil map. If it returns `nil` (Go) or `None`
-  (Python), `viam-server` treats this as an error.
-- Check network connectivity from the machine if your sensor reads from an
-  external source.
-
-{{< /expand >}}
-
-{{< expand "Module not restarting after code changes" >}}
-
-`viam-server` does not watch your module's source files or binary for changes.
-To deploy changes:
-
-- Use `viam module reload-local --part-id <id>` to rebuild and redeploy.
-- Use `viam module restart --part-id <id>` to restart without rebuilding.
-
-{{< /expand >}}
-
-{{< expand "Data capture not recording readings" >}}
-
-Data capture requires both the data management service and a per-resource
-capture configuration:
-
-- Verify the data management service is configured and does not have
-  `capture_disabled` set to `true`.
-- Verify your sensor component has a data capture configuration with
-  `capture_frequency_hz` greater than `0`.
-- Check that `GetReadings` returns a valid, non-nil map.
-- If the capture frequency is very low, you may need to wait longer to see
-  data appear on the [**Data** page](https://app.viam.com/data).
-
-{{< /expand >}}
-
-## What's Next
-
-- [Write a Logic Module](/operate/modules/write-a-logic-module/) -- write a module
-  that monitors sensors, coordinates components, or runs automation logic.
-- [Deploy a Module](/operate/modules/deploy-a-module/) -- package your module
-  and upload it to the Viam registry for distribution.
diff --git a/docs/operate/modules/write-a-logic-module.md b/docs/operate/modules/write-a-logic-module.md
deleted file mode 100644
index 8dd805619d..0000000000
--- a/docs/operate/modules/write-a-logic-module.md
+++ /dev/null
@@ -1,726 +0,0 @@
----
-linkTitle: "Write a Logic Module"
-title: "Write a Control Logic Module"
-weight: 25
-layout: "docs"
-type: "docs"
-description: "Build a module that monitors sensors, coordinates components, or runs automation logic."
-date: "2025-03-06"
-aliases:
-  - /development/write-a-logic-module/
-  - /operate/modules/control-logic/
-  - /manage/software/control-logic/
----
-
-Your machine has resources -- sensors, motors, cameras -- that work individually.
-A logic module makes them work together. It runs as a service alongside
-`viam-server`, declares dependencies on the resources it needs, and implements
-whatever control, monitoring, or coordination logic your application requires.
-
-Use a logic module when you need your machine to make decisions based on what
-it senses: trigger actions when readings cross a threshold, coordinate multiple
-components to accomplish a task, aggregate data from several sources, or run
-any continuous process that reads from some resources and acts on others.
-
-{{< alert title="Driver modules versus logic modules" color="tip" >}}
-A [driver module](/operate/modules/write-a-driver-module/) wraps hardware -- it implements
-a component API like sensor or motor so that `viam-server` can talk to a
-specific piece of hardware.
-
-A logic module (this page) orchestrates existing resources -- it reads from
-sensors, commands motors, and makes decisions. It typically implements a service
-API.
-
-Both are modules. The difference is what they do, not how they're built. The
-lifecycle, config validation, dependency, and deployment patterns are the same.
-{{< /alert >}}
-
-## Concepts
-
-### Module lifecycle
-
-Every module goes through a defined lifecycle:
-
-1. **Startup** -- `viam-server` launches the module as a separate process.
-2. **Validation** -- For each configured resource, `viam-server` calls a
-   validation method that checks config attributes and declares dependencies
-   on other resources.
-3. **Construction** -- `viam-server` calls the constructor with the validated
-   config and resolved dependencies.
-4. **Reconfiguration** -- If the user changes the config, `viam-server` calls
-   the validation method again, then the reconfiguration method.
-5. **Shutdown** -- `viam-server` calls the close method. Clean up resources
-   (including background tasks) here.
-
-For more detail, see [Module Lifecycle](/operate/modules/lifecycle-of-a-module/).
-
-### Dependencies
-
-A logic module typically depends on other resources on the machine -- the
-sensors it monitors, the motors it controls. You declare dependencies in your
-validation method by returning their names. `viam-server` ensures those
-resources are ready before calling your constructor, and passes them in as a
-map you can look up by name.
-
-The pattern has three steps:
-
-1. **Declare** -- return dependency names from your validation method.
-2. **Resolve** -- look up each dependency from the map in your constructor.
-3. **Use** -- call methods on the resolved dependencies in your logic.
-
-The code examples below mark each step with numbered comments.
-
-### The generic service API
-
-The `generic` service API has a single method: `DoCommand`. It accepts an
-arbitrary key-value map and returns one. This makes it a flexible interface for
-custom logic -- you define your own command vocabulary.
-
-```json
-// Request
-{"command": "get_alerts", "severity": "critical"}
-
-// Response
-{"alerts": [{"sensor": "temp-1", "value": 42.5, "threshold": 40.0}]}
-```
-
-Use `generic` when your module's interface doesn't map to an existing service
-API (like `vision` or `mlmodel`). For the full list of service APIs, see
-[Resource APIs](/reference/apis/).
-
-### Background tasks
-
-Logic modules often need to run continuously -- polling sensors, checking
-thresholds, updating state. You can spawn background tasks in Go or C++. It is not recommended to spawn background tasks in Python because they will conflict with the Viam SDK's background tasks. If you need to run background logic in a Python module, instead place the logic in `DoCommand` and create a scheduled job to run the task on a schedule.
-
-The key requirement: your background task must stop cleanly when the module
-shuts down or reconfigures. Use a cancellation signal (a channel in Go) to coordinate this.
-
-## Steps
-
-When writing a logic module, follow the steps outlined below. To illustrate
-each step we'll use a temperature alert monitor as a worked example. It watches
-one or more sensors, compares their readings against configurable thresholds,
-and maintains a list of active alerts that your application code can query.
-
-### 1. Generate a generic service module
-
-```bash
-viam module generate
-```
-
-| Prompt           | What to enter               | Why                              |
-| ---------------- | --------------------------- | -------------------------------- |
-| Module name      | `alert-monitor`             | A short, descriptive name        |
-| Language         | `python` or `go`            | Your implementation language     |
-| Visibility       | `private`                   | Keep it private while developing |
-| Namespace        | Your organization namespace | Scopes the module to your org    |
-| Resource subtype | `generic` (under services)  | Flexible service API             |
-| Model name       | `temp-alert`                | The model name for your service  |
-| Register         | `yes`                       | Registers the module with Viam   |
-
-The generator creates a complete project. The key files you will edit:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-| File                       | Purpose                                                     |
-| -------------------------- | ----------------------------------------------------------- |
-| `src/models/temp_alert.py` | Service class skeleton -- you will edit this                |
-| `src/main.py`              | Entry point -- starts the module server (no changes needed) |
-| `meta.json`                | Module metadata for the registry                            |
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-| File                 | Purpose                                                     |
-| -------------------- | ----------------------------------------------------------- |
-| `alert_monitor.go`   | Service implementation skeleton -- you will edit this       |
-| `cmd/module/main.go` | Entry point -- starts the module server (no changes needed) |
-| `meta.json`          | Module metadata for the registry                            |
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 2. Define the config
-
-Open the generated resource file. Define config attributes for the sensors to
-monitor and the alert thresholds.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-In `src/models/temp_alert.py`, add config attributes to your class:
-
-```python
-class TempAlert(Generic, EasyResource):
-    MODEL: ClassVar[Model] = Model(
-        ModelFamily("my-org", "alert-monitor"), "temp-alert"
-    )
-
-    sensor_names: list[str]
-    max_temp: float
-    poll_interval: float
-    alerts: list[dict]
-    _monitor_task: Optional[asyncio.Task]
-    _stop_event: asyncio.Event
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-In the generated `.go` file, add fields to the `Config` struct. Each field
-needs a `json` tag matching the attribute name users set in their config JSON.
-
-Then update the `Validate` method. It returns three values: a list of required
-dependency names, a list of optional dependency names, and an error.
-
-```go
-type Config struct {
-    SensorNames  []string `json:"sensor_names"`
-    MaxTemp      float64  `json:"max_temp"`
-    PollInterval float64  `json:"poll_interval_secs"`
-}
-
-func (cfg *Config) Validate(path string) ([]string, []string, error) {
-    if len(cfg.SensorNames) == 0 {
-        return nil, nil, fmt.Errorf("sensor_names is required")
-    }
-    if cfg.MaxTemp == 0 {
-        return nil, nil, fmt.Errorf("max_temp is required")
-    }
-    // 1. Declare: return all sensor names as required dependencies
-    return cfg.SensorNames, nil, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 3. Implement the constructor
-
-The constructor receives the validated config and a `dependencies` map
-containing the resources you declared in the validation method. Look up each
-dependency by name, store it on your struct/instance, and start the background
-monitoring loop.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-Update `validate_config`, `new`, and `reconfigure`:
-
-```python
-    @classmethod
-    def validate_config(
-        cls, config: ComponentConfig
-    ) -> Tuple[Sequence[str], Sequence[str]]:
-        fields = config.attributes.fields
-        if "sensor_names" not in fields:
-            raise Exception("sensor_names is required")
-        if "max_temp" not in fields:
-            raise Exception("max_temp is required")
-        sensor_names = [
-            v.string_value
-            for v in fields["sensor_names"].list_value.values
-        ]
-        # 1. Declare: return sensor names as required dependencies
-        return sensor_names, []
-
-    @classmethod
-    def new(cls, config: ComponentConfig,
-            dependencies: Mapping[ResourceName, ResourceBase]) -> Self:
-        instance = cls(config.name)
-        instance.alerts = []
-        instance._monitor_task = None
-        instance._stop_event = asyncio.Event()
-        instance.reconfigure(config, dependencies)
-        return instance
-
-    def reconfigure(self, config: ComponentConfig,
-                    dependencies: Mapping[ResourceName, ResourceBase]) -> None:
-        # Stop any existing monitor loop
-        if self._monitor_task is not None:
-            self._stop_event.set()
-            self._monitor_task = None
-
-        fields = config.attributes.fields
-        self.sensor_names = [
-            v.string_value
-            for v in fields["sensor_names"].list_value.values
-        ]
-        self.max_temp = fields["max_temp"].number_value
-        self.poll_interval = (
-            fields["poll_interval_secs"].number_value
-            if "poll_interval_secs" in fields
-            else 10.0
-        )
-
-        # 2. Resolve: find each sensor in the dependencies map
-        self.sensors = {}
-        for name, dep in dependencies.items():
-            if name.name in self.sensor_names:
-                self.sensors[name.name] = dep
-
-        # Start the monitor loop
-        self._stop_event = asyncio.Event()
-        self._monitor_task = asyncio.create_task(self._monitor_loop())
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-Update the struct and constructor. `resource.Named` provides the `Name()`
-method that `viam-server` requires. `resource.NativeConfig` converts the raw
-config into your typed struct. `sensor.FromProvider` looks up a sensor
-dependency by name from the dependencies map.
-
-```go
-type TempAlert struct {
-    resource.Named
-    logger   logging.Logger
-    cfg      *Config
-    sensors  map[string]sensor.Sensor
-    mu       sync.Mutex
-    alerts   []Alert
-    cancelFn func()
-}
-
-type Alert struct {
-    Sensor    string  `json:"sensor"`
-    Value     float64 `json:"value"`
-    Threshold float64 `json:"threshold"`
-    Time      string  `json:"time"`
-}
-
-func newTempAlert(
-    ctx context.Context,
-    deps resource.Dependencies,
-    conf resource.Config,
-    logger logging.Logger,
-) (resource.Resource, error) {
-    cfg, err := resource.NativeConfig[*Config](conf)
-    if err != nil {
-        return nil, err
-    }
-
-    // 2. Resolve: find each sensor in the dependencies map
-    sensors := make(map[string]sensor.Sensor)
-    for _, name := range cfg.SensorNames {
-        s, err := sensor.FromProvider(deps, name)
-        if err != nil {
-            return nil, fmt.Errorf("sensor %q not found: %w", name, err)
-        }
-        sensors[name] = s
-    }
-
-    monitorCtx, cancelFn := context.WithCancel(context.Background())
-    svc := &TempAlert{
-        Named:    conf.ResourceName().AsNamed(),
-        logger:   logger,
-        cfg:      cfg,
-        sensors:  sensors,
-        alerts:   []Alert{},
-        cancelFn: cancelFn,
-    }
-
-    // Start background monitor loop
-    go svc.monitorLoop(monitorCtx)
-
-    return svc, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 4. Implement the background loop
-
-The monitor loop polls sensors at a fixed interval and checks readings against
-thresholds. When a reading exceeds the threshold, it creates an alert.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-    async def _monitor_loop(self):
-        while not self._stop_event.is_set():
-            for name, s in self.sensors.items():
-                try:
-                    # 3. Use: call methods on dependencies
-                    readings = await s.get_readings()
-                    temp = readings.get("temperature")
-                    if temp is not None and temp > self.max_temp:
-                        alert = {
-                            "sensor": name,
-                            "value": temp,
-                            "threshold": self.max_temp,
-                            "time": datetime.now().isoformat(),
-                        }
-                        self.alerts.append(alert)
-                        self.logger.warning(
-                            "Alert: %s reported %.1f (threshold: %.1f)",
-                            name, temp, self.max_temp,
-                        )
-                except Exception as e:
-                    self.logger.error("Failed to read %s: %s", name, e)
-
-            try:
-                await asyncio.wait_for(
-                    self._stop_event.wait(),
-                    timeout=self.poll_interval,
-                )
-                break  # Stop event was set
-            except asyncio.TimeoutError:
-                pass  # Continue polling
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-func (s *TempAlert) monitorLoop(ctx context.Context) {
-    interval := time.Duration(s.cfg.PollInterval) * time.Second
-    if interval == 0 {
-        interval = 10 * time.Second
-    }
-
-    ticker := time.NewTicker(interval)
-    defer ticker.Stop()
-
-    for {
-        select {
-        case <-ctx.Done():
-            return
-        case <-ticker.C:
-            s.checkSensors(ctx)
-        }
-    }
-}
-
-func (s *TempAlert) checkSensors(ctx context.Context) {
-    s.mu.Lock()
-    defer s.mu.Unlock()
-
-    for name, sens := range s.sensors {
-        // 3. Use: call methods on dependencies
-        readings, err := sens.Readings(ctx, nil)
-        if err != nil {
-            s.logger.CErrorw(ctx, "failed to read sensor", "sensor", name, "error", err)
-            continue
-        }
-        temp, ok := readings["temperature"].(float64)
-        if !ok {
-            continue
-        }
-        if temp > s.cfg.MaxTemp {
-            alert := Alert{
-                Sensor:    name,
-                Value:     temp,
-                Threshold: s.cfg.MaxTemp,
-                Time:      time.Now().Format(time.RFC3339),
-            }
-            s.alerts = append(s.alerts, alert)
-            s.logger.CWarnw(ctx, "alert triggered",
-                "sensor", name, "value", temp, "threshold", s.cfg.MaxTemp)
-        }
-    }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< alert title="Note: lock scope" color="note" >}}
-The Go example holds the mutex for the entire `checkSensors` call, including sensor reads that may block on network IO.
-This keeps the code simple and familiar (`defer s.mu.Unlock()`), but it means `DoCommand` calls will block while sensors are being read.
-
-In production, you would copy `s.sensors` under the lock, release it, read sensors without the lock, then re-lock to append alerts.
-{{< /alert >}}
-
-### 5. Implement DoCommand
-
-`DoCommand` is the interface your application code uses to interact with the
-service. Define a command vocabulary that makes sense for your module.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-    async def do_command(
-        self,
-        command: Mapping[str, ValueTypes],
-        *,
-        timeout: Optional[float] = None,
-        **kwargs,
-    ) -> Mapping[str, ValueTypes]:
-        cmd = command.get("command", "")
-
-        if cmd == "get_alerts":
-            return {"alerts": self.alerts}
-
-        if cmd == "get_alert_count":
-            return {"count": len(self.alerts)}
-
-        if cmd == "acknowledge":
-            self.alerts.clear()
-            return {"status": "ok"}
-
-        if cmd == "set_threshold":
-            self.max_temp = command["max_temp"]
-            return {"status": "ok", "max_temp": self.max_temp}
-
-        raise Exception(f"Unknown command: {cmd}")
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-func (s *TempAlert) DoCommand(
-    ctx context.Context,
-    cmd map[string]interface{},
-) (map[string]interface{}, error) {
-    command, _ := cmd["command"].(string)
-
-    switch command {
-    case "get_alerts":
-        s.mu.Lock()
-        defer s.mu.Unlock()
-        // Convert alerts to interface slice for serialization
-        alertList := make([]interface{}, len(s.alerts))
-        for i, a := range s.alerts {
-            alertList[i] = map[string]interface{}{
-                "sensor":    a.Sensor,
-                "value":     a.Value,
-                "threshold": a.Threshold,
-                "time":      a.Time,
-            }
-        }
-        return map[string]interface{}{"alerts": alertList}, nil
-
-    case "get_alert_count":
-        s.mu.Lock()
-        defer s.mu.Unlock()
-        return map[string]interface{}{"count": len(s.alerts)}, nil
-
-    case "acknowledge":
-        s.mu.Lock()
-        defer s.mu.Unlock()
-        s.alerts = s.alerts[:0]
-        return map[string]interface{}{"status": "ok"}, nil
-
-    case "set_threshold":
-        newMax, ok := cmd["max_temp"].(float64)
-        if !ok {
-            return nil, fmt.Errorf("max_temp must be a number")
-        }
-        s.mu.Lock()
-        s.cfg.MaxTemp = newMax
-        s.mu.Unlock()
-        return map[string]interface{}{"status": "ok", "max_temp": newMax}, nil
-
-    default:
-        return nil, fmt.Errorf("unknown command: %s", command)
-    }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 6. Handle shutdown
-
-When `viam-server` stops the module or reconfigures it, your background loop
-must stop cleanly. Without this, goroutines or async tasks leak.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-    async def close(self):
-        self._stop_event.set()
-        if self._monitor_task is not None:
-            await self._monitor_task
-            self._monitor_task = None
-        self.logger.info("TempAlert monitor stopped")
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-func (s *TempAlert) Close(ctx context.Context) error {
-    s.cancelFn()
-    s.logger.CInfof(ctx, "TempAlert monitor stopped")
-    return nil
-}
-```
-
-In Go, the `Reconfigure` method should also stop the old loop and start a new
-one:
-
-```go
-func (s *TempAlert) Reconfigure(
-    ctx context.Context,
-    deps resource.Dependencies,
-    conf resource.Config,
-) error {
-    // Stop the old loop
-    s.cancelFn()
-
-    cfg, err := resource.NativeConfig[*Config](conf)
-    if err != nil {
-        return err
-    }
-
-    sensors := make(map[string]sensor.Sensor)
-    for _, name := range cfg.SensorNames {
-        sens, err := sensor.FromProvider(deps, name)
-        if err != nil {
-            return fmt.Errorf("sensor %q not found: %w", name, err)
-        }
-        sensors[name] = sens
-    }
-
-    monitorCtx, cancelFn := context.WithCancel(context.Background())
-
-    s.mu.Lock()
-    s.cfg = cfg
-    s.sensors = sensors
-    s.cancelFn = cancelFn
-    s.mu.Unlock()
-
-    go s.monitorLoop(monitorCtx)
-    return nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 7. Test locally
-
-**Configure the service on your machine:**
-
-1. In the [Viam app](https://app.viam.com), navigate to your machine's
-   **CONFIGURE** tab.
-2. Ensure you have at least one sensor configured (this is the resource your
-   logic module will monitor).
-3. Click **+**, select **Advanced**, then **Local module**.
-4. Set the **Executable path** to your module binary or script.
-5. Click **Create**.
-6. Click **+**, select **Advanced**, then **Local service**.
-7. Select your module, set the type to `generic` and the model to your model
-   name, and configure attributes:
-
-   ```json
-   {
-     "sensor_names": ["my-temp-sensor"],
-     "max_temp": 30.0,
-     "poll_interval_secs": 5
-   }
-   ```
-
-8. Click **Save**.
-
-**Test with DoCommand:**
-
-On the **CONFIGURE** tab, expand your service's card and find the **DoCommand**
-section. Send a command:
-
-```json
-{ "command": "get_alerts" }
-```
-
-You should see a response with any alerts that have been triggered.
-
-**Get a ready-to-run code sample:**
-
-The **CONNECT** tab on your machine's page in the Viam app provides generated
-code samples in Python and Go that connect to your machine and access all
-configured resources. Use this as a starting point for application code that
-sends `DoCommand` requests to your service.
-
-**Rebuild and redeploy during development:**
-
-`viam-server` does not automatically detect changes to your module's source
-files or binary. After making changes, use the CLI to rebuild and redeploy:
-
-```bash
-# Build locally, transfer to machine, and restart the module
-viam module reload-local --part-id <machine-part-id>
-
-# Restart the module without rebuilding (e.g., after editing Python source)
-viam module restart --part-id <machine-part-id>
-```
-
-**Test the alert flow:**
-
-1. Verify your sensor is returning temperature readings on the TEST card.
-2. Set `max_temp` to a value below the current temperature so alerts trigger.
-3. Wait for one poll interval, then send `{"command": "get_alerts"}`.
-4. You should see alerts in the response.
-5. Send `{"command": "acknowledge"}` to clear them.
-
-## Try It
-
-1. Generate a generic service module using `viam module generate`.
-2. Define config attributes for monitored sensors and thresholds.
-3. Implement the constructor to resolve sensor dependencies and start the
-   monitor loop.
-4. Implement `DoCommand` with `get_alerts`, `acknowledge`, and `set_threshold`
-   commands.
-5. Configure the module on your machine with a real sensor.
-6. Lower the threshold below the current temperature and verify alerts appear.
-
-## Troubleshooting
-
-{{< expand "Background loop not running" >}}
-
-- Check the **LOGS** tab for errors from the monitor loop. A failing sensor
-  read can cause the loop to exit silently.
-- Verify the `poll_interval_secs` is greater than 0.
-- In Python, ensure you are creating an `asyncio.Task` (not just calling the
-  async function without `await` or `create_task`).
-- In Go, ensure the goroutine context is not prematurely canceled. Use
-  `context.Background()` for the loop context, not the request context.
-
-{{< /expand >}}
-
-{{< expand "DoCommand returning unexpected results" >}}
-
-- Verify the `command` field in your request matches the command names in your
-  implementation exactly (case-sensitive).
-- Check that value types match. JSON numbers are `float64` in Go and `float`
-  in Python. If you send `"max_temp": 30`, Go receives it as `float64(30)`.
-- Add logging inside `DoCommand` to see the raw command map.
-
-{{< /expand >}}
-
-{{< expand "Sensor dependency not available" >}}
-
-- Confirm the sensor names in `sensor_names` match the names of sensors
-  configured on the machine exactly.
-- Verify the sensors are configured and working before the logic module starts.
-  Check the **CONTROL** tab to confirm each sensor returns readings.
-- If a sensor is added after the logic module is already running, reconfigure
-  the logic module (re-save its config) so `viam-server` re-resolves
-  dependencies.
-
-{{< /expand >}}
-
-{{< expand "Alerts not appearing" >}}
-
-- Check that your sensor's readings map includes a `"temperature"` key. The
-  monitor loop checks for this specific key.
-- Verify `max_temp` is set below the actual temperature so alerts trigger.
-- Check the **LOGS** tab for warning messages from the monitor loop.
-
-{{< /expand >}}
-
-## What's Next
-
-- [Write a Driver Module](/operate/modules/write-a-driver-module/) -- write a module
-  that wraps custom hardware.
-- [Deploy a Module](/operate/modules/deploy-a-module/) -- package and upload your
-  module to the Viam registry.
diff --git a/docs/operate/modules/write-an-inline-module.md b/docs/operate/modules/write-an-inline-module.md
deleted file mode 100644
index 25f6570090..0000000000
--- a/docs/operate/modules/write-an-inline-module.md
+++ /dev/null
@@ -1,570 +0,0 @@
----
-linkTitle: "Write an Inline Module"
-title: "Write an Inline Module"
-weight: 10
-layout: "docs"
-type: "docs"
-description: "Write and deploy a custom module directly in the browser using Viam's inline module editor."
-date: "2025-01-30"
-aliases:
-  - /build/development/write-an-inline-module/
-  - /development/write-an-inline-module/
----
-
-Viam provides built-in support for many types of hardware and software, but you
-may want to use hardware that Viam doesn't support out of the box, or add
-application-specific logic. Modules let you add that support yourself.
-
-An inline module is the fastest way to get started. You write your module code
-directly in the Viam app's browser-based editor -- no IDE, terminal, or GitHub
-account required. When you click **Save & Deploy**, Viam builds your module in
-the cloud and deploys it to your machine automatically.
-
-## Concepts
-
-### What is an inline module?
-
-An inline module is a Viam-hosted module. Viam manages the source code,
-versioning, builds, and deployment for you. You edit a single source file in the
-browser, and Viam handles everything else:
-
-- **Source code** is stored and versioned by Viam (not in a git repository).
-- **Builds** run automatically in the cloud when you save.
-- **Deployment** happens automatically -- machines configured with your module
-  receive the new version within minutes.
-
-### Inline modules versus externally managed modules
-
-|                          | Inline (Viam-hosted)                                   | Externally managed                                            |
-| ------------------------ | ------------------------------------------------------ | ------------------------------------------------------------- |
-| **Where you write code** | Browser editor in the Viam app                         | Your own IDE, locally or in a repo                            |
-| **Source control**       | Managed by Viam                                        | Your own git repository                                       |
-| **Build system**         | Automatic cloud builds on save                         | CLI upload or GitHub Actions                                  |
-| **Versioning**           | Automatic (`0.0.1`, `0.0.2`, ...)                      | You choose semantic versions                                  |
-| **Visibility**           | Private to your organization                           | Private or public                                             |
-| **Best for**             | Prototyping, simple control logic, no-toolchain setups | Production modules, public distribution, complex dependencies |
-
-Both types run identically at runtime -- as child processes communicating with
-`viam-server` over gRPC. The difference is how you create, edit, and deploy the
-module.
-
-If you want to manage your own source code and build pipeline, see
-[Write a Driver Module](/operate/modules/write-a-driver-module/) or
-[Write a Logic Module](/operate/modules/write-a-logic-module/) instead.
-
-### The Generic service
-
-Inline modules create a Generic **service** (not a component). The Generic
-service provides a single method -- `DoCommand` -- that accepts an arbitrary
-JSON command and returns a JSON response. Your control logic goes inside
-`DoCommand`.
-
-Use the Generic service when:
-
-- You want to coordinate multiple components (read a sensor, move a servo).
-- You need a simple command-response interface.
-- You are prototyping and want to iterate quickly.
-
-## Steps
-
-### 1. Create the module
-
-1. In the [Viam app](https://app.viam.com), navigate to your machine's
-   **CONFIGURE** tab.
-2. Click **+** and select **Control code**.
-3. In the "Choose where to host your code" dialog, select **Viam-hosted** and
-   click **Choose**.
-4. Name your module (for example, `servo-distance-control`) and choose a language
-   (**Python** or **Go**).
-5. Click **Create module**.
-
-The browser opens the code editor with a working template that includes all
-necessary imports and method stubs.
-
-### 2. Understand the template
-
-The editor opens a single file -- your module's main source file. The template
-includes three methods you need to fill in:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-The editable file is `src/models/generic_service.py`. It contains a class that
-extends `GenericService` and `EasyResource`:
-
-```python
-class MyGenericService(GenericService, EasyResource):
-    MODEL: ClassVar[Model] = Model(
-        ModelFamily("my-org", "my-module"), "generic-service"
-    )
-```
-
-The three methods to implement:
-
-- **`validate_config`** -- check that configuration attributes are valid and
-  declare dependencies.
-- **`new`** -- initialize your service with attributes and dependencies.
-- **`do_command`** -- your control logic.
-
-{{< alert title="Important" color="caution" >}}
-Do not change the class name or the `MODEL` triplet. Viam uses these
-auto-generated values to identify your module. Changing them will break your
-inline module.
-{{< /alert >}}
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-The editable file is `module.go`. It contains a struct, a config type, and
-registration logic:
-
-```go
-var GenericService = resource.NewModel(
-    "my-org", "my-module", "generic-service",
-)
-
-func init() {
-    resource.RegisterService(genericservice.API, GenericService,
-        resource.Registration[resource.Resource, *Config]{
-            Constructor: newGenericService,
-        },
-    )
-}
-```
-
-The three areas to implement:
-
-- **`Validate`** on the `Config` struct -- check attributes, return
-  dependencies.
-- **`NewGenericService`** -- initialize the service with attributes and
-  dependencies.
-- **`DoCommand`** -- your control logic.
-
-{{< alert title="Important" color="caution" >}}
-Do not change the model name triplet, struct names, or public function names.
-Viam uses these auto-generated values to identify your module. Changing them
-will break your inline module.
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 3. Implement validate_config
-
-The validate method runs every time the machine configuration changes. It checks
-that the attributes passed to your service are valid and declares dependencies
-on other components or services.
-
-This example validates attributes for a distance-responsive servo controller --
-a service that reads an ultrasonic sensor and adjusts a servo angle based on
-distance:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-@classmethod
-def validate_config(
-    cls, config: ComponentConfig
-) -> Tuple[Sequence[str], Sequence[str]]:
-    attrs = struct_to_dict(config.attributes)
-
-    # Required numeric attributes
-    sensor_range_start = attrs.get("sensor_range_start")
-    if sensor_range_start is None or not isinstance(
-        sensor_range_start, (int, float)
-    ):
-        raise ValueError(
-            "attribute 'sensor_range_start' is required "
-            "and must be an int or float value"
-        )
-
-    sensor_range_end = attrs.get("sensor_range_end")
-    if sensor_range_end is None or not isinstance(
-        sensor_range_end, (int, float)
-    ):
-        raise ValueError(
-            "attribute 'sensor_range_end' is required "
-            "and must be an int or float value"
-        )
-
-    # Required dependency attributes
-    required_deps: List[str] = []
-
-    servo_name = attrs.get("servo")
-    if not isinstance(servo_name, str) or not servo_name:
-        raise ValueError(
-            "attribute 'servo' (non-empty string) is required"
-        )
-    required_deps.append(servo_name)
-
-    sensor_name = attrs.get("sensor")
-    if not isinstance(sensor_name, str) or not sensor_name:
-        raise ValueError(
-            "attribute 'sensor' (non-empty string) is required"
-        )
-    required_deps.append(sensor_name)
-
-    return required_deps, []
-```
-
-The return value is a tuple of two lists:
-
-1. **Required dependencies** -- component or service names that must exist and
-   be ready before your service starts.
-2. **Optional dependencies** -- names your service can use if available but
-   does not require.
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-type Config struct {
-    SensorRangeStart float64 `json:"sensor_range_start"`
-    SensorRangeEnd   float64 `json:"sensor_range_end"`
-    ServoAngleMin    *int64  `json:"servo_angle_min"`
-    ServoAngleMax    *int64  `json:"servo_angle_max"`
-    Reversed         *bool   `json:"reversed"`
-    Servo            string  `json:"servo"`
-    Sensor           string  `json:"sensor"`
-}
-
-func (cfg *Config) Validate(path string) ([]string, []string, error) {
-    if cfg.SensorRangeStart == 0 {
-        return nil, nil, fmt.Errorf(
-            "%s: 'sensor_range_start' is required and must be non-zero",
-            path,
-        )
-    }
-    if cfg.SensorRangeEnd == 0 {
-        return nil, nil, fmt.Errorf(
-            "%s: 'sensor_range_end' is required and must be non-zero",
-            path,
-        )
-    }
-
-    requiredDeps := []string{}
-    if cfg.Servo == "" {
-        return nil, nil, fmt.Errorf(
-            "%s: 'servo' (non-empty string) is required", path,
-        )
-    }
-    requiredDeps = append(requiredDeps, cfg.Servo)
-
-    if cfg.Sensor == "" {
-        return nil, nil, fmt.Errorf(
-            "%s: 'sensor' (non-empty string) is required", path,
-        )
-    }
-    requiredDeps = append(requiredDeps, cfg.Sensor)
-
-    return requiredDeps, []string{}, nil
-}
-```
-
-The `Validate` method returns two slices (required dependencies and optional
-dependencies) and an error.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 4. Implement the constructor
-
-The constructor runs when the service is first created and again whenever its
-configuration changes. Use it to parse attributes and resolve dependencies.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-@classmethod
-def new(
-    cls, config: ComponentConfig,
-    dependencies: Mapping[ResourceName, ResourceBase]
-) -> Self:
-    attrs = struct_to_dict(config.attributes)
-    self = cls(config.name)
-
-    # Required attributes
-    self.sensor_range_start = float(attrs.get("sensor_range_start"))
-    self.sensor_range_end = float(attrs.get("sensor_range_end"))
-
-    # Optional attributes with defaults
-    self.servo_angle_min = float(attrs.get("servo_angle_min", 0))
-    self.servo_angle_max = float(attrs.get("servo_angle_max", 180))
-    self.reversed = attrs.get("reversed", False)
-
-    # Resolve dependencies
-    servo_name = attrs.get("servo")
-    sensor_name = attrs.get("sensor")
-    self.servo = dependencies[Servo.get_resource_name(servo_name)]
-    self.sensor = dependencies[Sensor.get_resource_name(sensor_name)]
-
-    return self
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-func NewGenericService(
-    ctx context.Context, deps resource.Dependencies,
-    name resource.Name, conf *Config, logger logging.Logger,
-) (resource.Resource, error) {
-    cancelCtx, cancelFunc := context.WithCancel(context.Background())
-
-    // Apply defaults for optional fields
-    servoAngleMin := int64(0)
-    if conf.ServoAngleMin != nil {
-        servoAngleMin = *conf.ServoAngleMin
-    }
-    servoAngleMax := int64(180)
-    if conf.ServoAngleMax != nil {
-        servoAngleMax = *conf.ServoAngleMax
-    }
-    reversed := false
-    if conf.Reversed != nil {
-        reversed = *conf.Reversed
-    }
-
-    // Resolve dependencies
-    servoDep, err := servo.FromProvider(deps, conf.Servo)
-    if err != nil {
-        return nil, err
-    }
-    sensorDep, err := sensor.FromProvider(deps, conf.Sensor)
-    if err != nil {
-        return nil, err
-    }
-
-    return &genericService{
-        name:             name,
-        logger:           logger,
-        cfg:              conf,
-        cancelCtx:        cancelCtx,
-        cancelFunc:       cancelFunc,
-        servo:            servoDep,
-        sensor:           sensorDep,
-        sensorRangeStart: conf.SensorRangeStart,
-        sensorRangeEnd:   conf.SensorRangeEnd,
-        servoAngleMin:    servoAngleMin,
-        servoAngleMax:    servoAngleMax,
-        reversed:         reversed,
-    }, nil
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### 5. Implement DoCommand
-
-`DoCommand` is where your control logic goes. This example reads a distance
-sensor and maps the reading to a servo angle:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python
-async def do_command(
-    self, command: Mapping[str, ValueTypes], *,
-    timeout: Optional[float] = None, **kwargs
-) -> Mapping[str, ValueTypes]:
-    readings = await self.sensor.get_readings()
-    if not readings:
-        raise ValueError("No sensor readings available")
-
-    value = next(iter(readings.values()))
-
-    # Map sensor range to servo angle range
-    t = (value - self.sensor_range_start) / (
-        self.sensor_range_end - self.sensor_range_start
-    )
-    t = max(0.0, min(1.0, 1.0 - t if self.reversed else t))
-
-    angle = self.servo_angle_min + t * (
-        self.servo_angle_max - self.servo_angle_min
-    )
-    await self.servo.move(int(angle))
-
-    return {"servo_angle_deg": angle}
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go
-func (s *genericService) DoCommand(
-    ctx context.Context, cmd map[string]interface{},
-) (map[string]interface{}, error) {
-    readings, err := s.sensor.Readings(ctx, nil)
-    if err != nil {
-        return nil, err
-    }
-    value, ok := readings["distance"].(float64)
-    if !ok {
-        return nil, fmt.Errorf("sensor reading 'distance' must be a float64")
-    }
-
-    // Map sensor range to servo angle range
-    t := (value - s.sensorRangeStart) /
-        (s.sensorRangeEnd - s.sensorRangeStart)
-    if t < 0 { t = 0 } else if t > 1 { t = 1 }
-    if s.reversed { t = 1 - t }
-
-    angle := float64(s.servoAngleMin) +
-        t * (float64(s.servoAngleMax) - float64(s.servoAngleMin))
-    return map[string]interface{}{
-        "servo_angle_deg": angle,
-    }, s.servo.Move(ctx, uint32(angle), nil)
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-In this example no DoCommand payload is used. You can use the command payload to
-customize behavior per invocation. Attributes are constant across all
-invocations; the DoCommand payload can vary with each call.
-
-### 6. Save and deploy
-
-1. Click **Save & Deploy** in the code editor toolbar.
-2. Viam uploads your code as a new version and starts a cloud build.
-3. Builds typically take 2-5 minutes. You can continue editing while a build
-   runs -- your next save creates a new version.
-4. If the build fails, click **View Logs** to see what went wrong.
-
-Each save creates a new version in your module's history. You can switch between
-versions using the version dropdown in the editor toolbar.
-
-### 7. Test on a machine
-
-#### Add the module to a machine
-
-1. In the code editor, click **Add to machine**.
-2. Select a location, machine, and part.
-3. Click **Add**.
-
-The Viam app navigates you to the machine's **CONFIGURE** tab with your module
-added.
-
-#### Configure the service
-
-1. In the module section, click **Add** to add a model of your generic service.
-2. Click **+** to add each dependency your service requires (for example, a servo and
-   a sensor). Configure each dependency with the appropriate attributes.
-3. Configure the attributes for your generic service:
-
-```json
-{
-  "sensor_range_start": 0.05,
-  "sensor_range_end": 0.3,
-  "servo_angle_min": 40,
-  "servo_angle_max": 270,
-  "reversed": true,
-  "servo": "servo-1",
-  "sensor": "sensor-1"
-}
-```
-
-4. Click **Save**.
-
-#### Send test commands
-
-1. On the **CONFIGURE** tab, expand your generic service's card.
-2. Find the **DoCommand** section.
-3. Enter a command (or an empty map `{}` if your DoCommand does not use the
-   payload):
-
-```json
-{}
-```
-
-4. Click **Execute**. You should see a response like:
-
-```json
-{ "servo_angle_deg": 155.0 }
-```
-
-### 8. Automate with a scheduled job
-
-The DoCommand section in the Viam app runs your logic once per click. To have
-it run automatically:
-
-1. Click **+** and select **Job**.
-2. Name the job and click **Create**.
-3. Choose a schedule. For control logic that should always run, select
-   **Continuous**.
-4. Select your generic service as the resource.
-5. Edit the DoCommand payload or leave it as an empty map if no payload is
-   needed.
-6. Click **Save**.
-
-## Try It
-
-1. Create a new inline module from the **+** menu.
-2. Implement `validate_config`, the constructor, and `do_command`.
-3. Click **Save & Deploy** and wait for the build to complete.
-4. Add the module to a machine and configure the service with dependencies.
-5. Execute a DoCommand and verify the response.
-6. Set up a scheduled job to run the logic continuously.
-
-## Troubleshooting
-
-{{< expand "\"Viam-hosted\" option not visible" >}}
-
-The inline module feature is gated by a feature flag. If you do not see the
-"Viam-hosted" option when clicking **+** → **Control code**, your organization
-may not have the feature enabled. Contact Viam support to request access.
-
-{{< /expand >}}
-
-{{< expand "Build fails after saving" >}}
-
-- Click **View Logs** in the build progress bar to see the error.
-- Common causes: syntax errors, missing imports, incompatible dependencies.
-- You can fix the code and save again -- each save creates a new version.
-
-{{< /expand >}}
-
-{{< expand "Module not appearing on machine" >}}
-
-- Verify the machine is online and connected to the cloud.
-- Check that you added the module using the **Add to machine** button in the
-  code editor, or that the module appears in the machine's configuration.
-- The module version defaults to `latest`. After a successful build, the machine
-  picks up the new version automatically within a few minutes.
-
-{{< /expand >}}
-
-{{< expand "DoCommand returns an error" >}}
-
-- Check that all dependencies are configured on the machine and are working.
-  Use the test section of each dependency to verify them in isolation.
-- Verify the attribute names in your service configuration match what
-  `validate_config` expects.
-- Check the **LOGS** tab for detailed error messages.
-
-{{< /expand >}}
-
-{{< expand "Changes to code not taking effect" >}}
-
-- Make sure the build completed successfully. Check the build progress bar in
-  the code editor.
-- The machine must be online to receive the updated module. Check the machine's
-  status in the Viam app.
-- By default, modules are configured with version `latest`, which means every
-  new build deploys automatically. If the version is pinned, update it manually.
-
-{{< /expand >}}
-
-## What's Next
-
-- [Write a Driver Module](/operate/modules/write-a-driver-module/) -- build a module
-  with a typed resource API when you need to manage your own source code and
-  build pipeline.
-- [Write a Logic Module](/operate/modules/write-a-logic-module/) -- build control
-  logic as an externally managed module with full IDE support.
-- [Deploy a Module](/operate/modules/deploy-a-module/) -- package and upload
-  a module to the Viam registry for distribution to other machines or users.
diff --git a/docs/operate/reference/_index.md b/docs/operate/reference/_index.md
deleted file mode 100644
index 07322e7399..0000000000
--- a/docs/operate/reference/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-linkTitle: "Reference"
-weight: 300
-layout: "empty"
-type: "docs"
-empty_node: true
-header_only: true
-canonical: "/operate/reference/architecture/"
----
diff --git a/docs/operate/reference/advanced-modules/_index.md b/docs/operate/reference/advanced-modules/_index.md
deleted file mode 100644
index 9d35dbcc29..0000000000
--- a/docs/operate/reference/advanced-modules/_index.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: "Advanced modular resources"
-linkTitle: "Advanced modular resources"
-type: docs
-tags:
-  [
-    "server",
-    "rdk",
-    "extending viam",
-    "modular resources",
-    "components",
-    "services",
-  ]
-description: "Some usage may require you to define new APIs or deploy custom components in non-standard ways."
-aliases:
-  - /program/extend/
-  - /modular-resources/advanced/
-  - /registry/advanced/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-toc_hide: true
----
-
-Some use cases may require advanced considerations when designing or deploying modular resources.
-Depending on your needs, you may wish to define an entirely new resource API, deploy a custom component using a server on a {{< glossary_tooltip term_id="remote-part" text="remote" >}} {{< glossary_tooltip term_id="part" text="part" >}}, or design a custom ML model.
-
-## New APIs
-
-The [component APIs](/reference/apis/#component-apis) and [service APIs](/reference/apis/#service-apis) provide a standard interface for controlling common hardware components and higher level functionality.
-If your use case aligns closely with an existing API, you should use that API to program your new resource.
-
-If you want to use most of an existing API but need just a few other functions, you can use the `DoCommand` endpoint together with [extra parameters](/reference/sdks/use-extra-params/) to add custom functionality to an existing resource API.
-
-Or, if your resource does not fit into an existing resource API, you can use one of the following:
-
-- If you are working with a component that doesn't fit into any of the existing [component APIs](/reference/apis/#component-apis), you can use the [generic component](/operate/reference/components/generic/) to build your own component API.
-- If you are designing a service that doesn't fit into any of the existing [service APIs](/reference/apis/#service-apis), you can use the [generic service](/reference/apis/services/generic/) to build your own service API.
-
-Both generic resources use the [`DoCommand`](/reference/apis/components/generic/#docommand) endpoint to enable you to make arbitrary calls as needed for your resource.
-
-Alternatively, you can also [define a new resource API](/operate/reference/advanced-modules/create-subtype/) if none of the above options are a good fit for your use case.
-
-## Custom components as remotes
-
-Running {{< glossary_tooltip term_id="modular-resource" text="modular resources" >}} on the computer directly connected to your components is the preferred way of managing and controlling custom components.
-
-However, if you are unable to use modular resources because you need to host `viam-server` on a non-Linux system or have an issue with compilation, you may need to [implement a custom component and register it on a server configured as a remote](/operate/reference/advanced-modules/custom-components-remotes/) on your machine.
-
-## Deploy a module using Docker
-
-If you need to package and deploy a module using Docker, for example if your module relies on complex system dependencies, see [Deploy a module using Docker](/operate/reference/advanced-modules/docker-modules/) for suggestions.
-
-## Design a custom ML model
-
-When working with the [ML model service](/reference/apis/services/ml/), you can deploy an [existing model](/vision/configure/) or [train your own model](/train/custom-training-scripts/).
-
-However, if you are writing your own {{< glossary_tooltip term_id="module" text="module" >}} that uses the ML model service together with the [vision service](/reference/apis/services/vision/), you can also [design your own ML model](/data-ai/reference/mlmodel-design/) to better match your specific use case.
diff --git a/docs/operate/reference/advanced-modules/create-subtype.md b/docs/operate/reference/advanced-modules/create-subtype.md
deleted file mode 100644
index f88c17fb94..0000000000
--- a/docs/operate/reference/advanced-modules/create-subtype.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: "Define a new resource API"
-linkTitle: "Custom API"
-weight: 30
-type: "docs"
-tags: ["rdk", "extending viam", "modular resources", "API"]
-description: "Define a custom API for a resource that does not fit into existing component or service APIs."
-no_list: true
-aliases:
-  - /extend/modular-resources/create/create-subtype/
-  - /modular-resources/advanced/create-subtype/
-  - /registry/advanced/create-subtype/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-You can define a new, custom {{< glossary_tooltip term_id="resource" text="resource" >}} API if:
-
-- You have a {{% glossary_tooltip term_id="resource" text="resource" %}} that does not fit into any of the existing {{< glossary_tooltip term_id="component" text="component" >}} or {{< glossary_tooltip term_id="service" text="service" >}} APIs.
-- You have a resource that could fit into an existing API, but you want to define an API with different methods and messages than the one in the existing [APIs](/reference/apis/).
-
-{{% alert title="Tip" color="tip" %}}
-
-Defining a new resource API is significantly more complex than using an existing API.
-In most cases, you should try to use an existing API rather than define a new one.
-
-If you want to use most of an existing API but need just a few other functions, try using the `DoCommand` endpoint and [extra parameters](/reference/sdks/use-extra-params/) to add custom functionality to an existing API.
-For example, if you have a [sensor](/operate/reference/components/sensor/) and you want to define a `Calibrate` method, you can use `DoCommand`.
-
-If your use case uses only `DoCommand` and no other API methods, you can define a new model of [generic component](/operate/reference/components/generic/) or [generic service](/operate/reference/services/generic/).
-
-{{% /alert %}}
-
-## Define your new resource API
-
-Viam uses [protocol buffers](https://protobuf.dev/) for API definition.
-
-To define a new API, you need to define the methods and messages of the API in [protobuf](https://github.com/protocolbuffers/protobuf), write code in Python or Go to implement the higher level server and client functions required, and generate all necessary [protobuf module files](https://buf.build/docs/generate/usage/).
-The following steps guide you through this process in more detail:
-
-1. Decide whether your custom API is a {{< glossary_tooltip term_id="component" text="component" >}} or a {{< glossary_tooltip term_id="service" text="service" >}}.
-   If it provides an interface to control hardware, it is a component.
-   If it provides higher-level functionality, it is a service.
-1. Choose a name for your API.
-   This is called the `{{< glossary_tooltip term_id="subtype" text="subtype" >}}` of your API.
-   For example, `gizmo`.
-
-   Determine a valid {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet" >}} based on your API name.
-   You can figure out the {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet" >}} later when you [create a model that implements your custom API](/operate/modules/write-a-driver-module/).
-
-   {{< expand "API namespace triplet and model namespace triplet example" >}}
-
-   The `viam-labs:audioout:pygame` model uses the module name [audioout](https://github.com/viam-labs/audioout).
-   It implements the custom API `viam-labs:service:audioout`:
-
-   ```json
-   {
-     "api": "viam-labs:service:audioout",
-     "model": "viam-labs:audioout:pygame"
-   }
-   ```
-
-   For your custom API, your API namespace triplet might be `your-org-namespace:component:gizmo` where `your-org-namespace` is your organization namespace, found in your org settings page.
-
-   {{< /expand >}}
-
-1. Create a directory for your module.
-   Within that, create a directory called <file>src</file>.
-
-   {{% alert title="Tip" color="tip" %}}
-
-   If you are writing your module using Python, you can use this [module generator tool](https://github.com/viam-labs/generator-viam-module) to generate stub files for the new API as well as a new {{< glossary_tooltip term_id="module" text="module" >}} that implements the new API.
-
-   {{% /alert %}}
-
-1. Define your new API:
-
-   - [Write the proto](https://protobuf.dev/programming-guides/proto3/) methods in a `<API name>.proto` file inside your <file>src/proto</file> directory.
-     For reference:
-     - [Example modular component proto file](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/proto/gizmo.proto)
-     - [Example modular service proto file](https://github.com/viam-labs/speech-service-api/blob/main/src/proto/speech.proto)
-     - [Built-in Viam resource proto files](https://github.com/viamrobotics/api/tree/main/proto/viam)
-   - And define the proto methods in a protobuf-supported language such as Python or Go in a file called `api.py` or `api.go`, respectively.
-     - [Example component in Python](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/gizmo/api.py)
-     - [Example service in Python](https://github.com/viam-labs/speech-service-api/blob/main/src/speech_service_api/api.py)
-
-1. In the root directory of your module, you need to generate some configuration files.
-   You will typically need the following three files for most modules, though different files are required for some advanced use cases.
-   See the [Buf documentation](https://buf.build/docs/generate/usage/) for instructions.
-
-   - [<file>buf.yaml</file>](https://buf.build/docs/configuration/v1/buf-gen-yaml/)
-   - [<file>buf.gen.yaml</file>](https://buf.build/docs/configuration/v1/buf-gen-yaml/)
-   - [<file>buf.lock</file>](https://buf.build/docs/configuration/v1/buf-lock/)
-
-1. In the <file>/src/</file> directory of your module, use the protobuf compiler to [generate](https://buf.build/docs/tutorials/getting-started-with-buf-cli/#generate-code) all other necessary protocol buffer code, based on the `<API name>.proto` file you wrote.
-   - [Example generated files for a Python-based service](https://github.com/viam-labs/speech-service-api/tree/main/src/proto).
-     The `buf.` files were generated.
-     The <file>speech.proto</file> was manually written.
-
-## Next steps
-
-{{< cards >}}
-{{% manualcard link="/operate/modules/write-a-driver-module/" %}}
-
-<h4>Implement your API</h4>
-
-Now that your resource API is defined, create a new model that implements your new API.
-
-{{% /manualcard %}}
-{{< /cards >}}
-
-{{% alert title="Note" color="note" %}}
-
-After you define a new API and create a model that implements it, keep the following in mind when writing code against your new API:
-
-- You can't use [SDKs](/reference/sdks/) to call your new API unless you build out the client to support it.
-  It is easiest to write code against your new API in the language you used to define it.
-- Since your API doesn't have built-in SDK support, you'll need a local copy of the module code on whatever machine is running client code against it.
-- Be sure to import the API definition from the module directory, for example in Python it would be of the form `from path.to.module.src.gizmo import Gizmo`.
-  This example module written in Python uses a [Python script](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/client.py) to call the custom API from within the module directory.
-
-{{% /alert %}}
diff --git a/docs/operate/reference/advanced-modules/custom-components-remotes.md b/docs/operate/reference/advanced-modules/custom-components-remotes.md
deleted file mode 100644
index 8c10f98573..0000000000
--- a/docs/operate/reference/advanced-modules/custom-components-remotes.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: "Add custom components as remote parts"
-linkTitle: "Custom components as remote parts"
-weight: 99
-type: "docs"
-tags: ["server", "sdk"]
-aliases:
-  - /program/extend/sdk-as-server/
-  - /program/extend/custom-components-remotes/
-  - /extend/custom-components-remotes/
-  - /modular-resources/advanced/custom-components-remotes/
-  - /registry/advanced/custom-components-remotes/
-description: "If you are unable to use modular resources, you can implement custom components and register them on a server configured as a remote of your machine."
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-Running {{< glossary_tooltip term_id="modular-resource" text="modular resources" >}} on the computer directly connected to your components is the preferred way of managing and controlling custom components.
-
-However, if you are unable to use [modular resources](/operate/modules/write-a-driver-module/) because you need to host `viam-server` on a non-Linux system or have an issue with compilation, you can use a [Viam SDK](/reference/sdks/) to code a custom resource implementation, host it on a server, and add it as a [remote part](/operate/reference/architecture/parts/) of your machine.
-
-Once you have coded your custom component and configured the remote servers, you can control and monitor your component with the Viam SDKs, like any other component.
-
-To show how to create a custom resource, the following example creates an arm as a custom component and registers the new arm model with a Viam SDK.
-Then you can control it as part of your machine with the same [API methods](/reference/apis/components/arm/#api) available for [arm models built into the RDK](/operate/reference/components/arm/#configuration).
-
-## Instructions
-
-To add a custom resource as a [remote part](/operate/reference/architecture/parts/):
-
-{{< tabs >}}
-{{% tab name="Go" %}}
-
-1. Code a new model of a built-in resource type.
-   You can do this by creating a new interface that implements required methods.
-   The new model must implement any functions of the built-in resource type marked as required in its [RDK API definition](/reference/apis/).
-2. Register the custom component on a new gRPC server instance and start the server.
-3. Add the server as a [remote part](/operate/reference/architecture/parts/) of your machine.
-4. (Optional) Ensure the remote server automatically starts when the machine boots.
-
-Each remote server can host one or many custom components.
-
-{{% /tab %}}
-{{% tab name="Python" %}}
-
-{{< alert title="Tip" color="tip" >}}
-For more detailed instructions, see the full example in the [Python SDK documentation](https://python.viam.dev/examples/example.html#subclass-a-component).
-{{< /alert >}}
-
-1. Code a new model of a built-in resource type.
-   You can do this by subclassing a built in resource type like `sensor` or `arm`.
-   The new model must implement any methods of the built-in resource type marked as required in its [RDK API definition](/reference/apis/).
-1. Register the custom component on a new gRPC server instance and start the server.
-   You can do this with the [`viam.rpc` library](https://python.viam.dev/autoapi/viam/rpc/index.html) by creating a new `rpc.server.Server` instance.
-1. Add the server as a [remote part](/operate/reference/architecture/parts/) of your machine.
-1. (Optional) Ensure the remote server automatically starts when the machine boots.
-
-Each remote server can host one or many custom components.
-
-{{% /tab %}}
-{{% /tabs %}}
-
-{{% alert title="Important" color="note" %}}
-
-You must define all methods belonging to a built-in resource type when defining a new model.
-Otherwise, the class will not instantiate.
-
-- If you are using the Python SDK, raise an `NotImplementedError()` in the body of functions you do not want to implement or put `pass`.
-- If you are using the Go SDK, return `errUnimplemented`.
-- Additionally, return any values designated in the function's return signature, typed correctly.
-
-{{% /alert %}}
diff --git a/docs/operate/reference/advanced-modules/docker-modules.md b/docs/operate/reference/advanced-modules/docker-modules.md
deleted file mode 100644
index 0ab8094aca..0000000000
--- a/docs/operate/reference/advanced-modules/docker-modules.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: "Deploy a module using Docker"
-linkTitle: "Docker Modules"
-weight: 300
-type: "docs"
-tags: ["extending viam", "modular resources"]
-description: "Deploy a module using Docker."
-no_list: true
-date: "2025-04-10"
-# updated: ""  # When the content was last entirely checked
----
-
-In rare cases, you may need to package and deploy a module using Docker.
-Use cases for this include:
-
-- Your module has complex system dependencies that cannot be easily installed on a machine.
-- You use a large container image and some layers are already used by your machine which means layer caching can reduce the size of the download.
-- You have specific security requirements that are difficult to meet with the default module deployment.
-
-If you choose to deploy your module using Docker, we recommend creating a "first run" script or binary to run any necessary setup steps.
-Note this is _not_ recommended for modules that do not use Docker, as it adds unnecessary complexity.
-
-## Use a `first_run` script or binary
-
-1. Create a tarball that contains:
-
-   - The module's entrypoint script or binary, for example:
-
-     ```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-     #!/bin/bash
-     exec docker run <YOUR_CONTAINER_IMAGE> <YOUR_CONTAINER_OPTIONS>
-     ```
-
-   - A [<file>meta.json</file>](/operate/modules/advanced/metajson/)
-   - A first run script or binary that will be executed during the setup phase, for example:
-
-     ```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-     #!/usr/bin/env bash
-
-     docker pull mongo:6
-
-     cat << EOF
-     -------------------------------------
-     The setup script ran successfully!
-     -------------------------------------
-     EOF
-
-     exit 0
-     ```
-
-   [This example Makefile on GitHub](https://github.com/viam-labs/wifi-sensor/blob/7823b6ad3edcbbbf20b06c34b3181453f5f3f078/Makefile) builds a module binary and bundles it along with a <file>meta.json</file> and first run script.<br><br>
-
-1. Edit the <file>meta.json</file> to include a `first_run` field that points to the first run script or binary.
-
-   ```json
-   {
-     ...
-     "first_run": "first_run.sh"
-   }
-   ```
-
-1. Configure your module on your machine in the same way you would configure a regular module.
-   The first run script will execute once when `viam-server` receives a new configuration.
-   It will only execute once per module or per version of the module.<br><br>
-
-1. (Optional) After a first run script runs successfully, Viam adds a marker file in the module's data directory.
-   The marker file path format is of the form `unpackedModDir + FirstRunSuccessSuffix`.
-   For example, `.viam/packages/data/module/abcd1234-abcd-abcd-abcd-abcd12345678-viam-rtsp-0_1_0-linux-amd64/bin.first_run_succeeded`.
-
-   If you want to force a first run script to run again without changing the configured module or module version, you can do so by deleting this file.<br><br>
-
-1. (Optional) By default, a first run script will timeout after 1 hour.
-   This can be adjusted by adding a `first_run_timeout` to the module's configuration.
-   For example, `"first_run_timeout": "5m"` will lower the script timeout to 5 minutes.
diff --git a/docs/operate/reference/architecture/_index.md b/docs/operate/reference/architecture/_index.md
deleted file mode 100644
index c3914a6976..0000000000
--- a/docs/operate/reference/architecture/_index.md
+++ /dev/null
@@ -1,214 +0,0 @@
----
-title: "Viam architecture"
-linkTitle: "Viam architecture"
-weight: 10
-type: "docs"
-description: "How a machine running on Viam is structured, from on-device to cloud communications."
-imageAlt: "Viam architecture"
-images: ["/viam/machine-components.png"]
-tags: ["components", "services", "communication"]
-date: "2024-08-13"
-aliases:
-  - /architecture/
-# updated: ""  # When the content was last entirely checked
----
-
-This page provides an overview of how a machine is structured, including on-device and cloud communications:
-
-- [`viam-server` and `viam-micro-server`](#viam-server-and-viam-micro-server)
-- [Components, services and modules](#components-services-modules)
-- [Communication flow and security](#communication)
-- [How data flows in Viam](#data-management-flow)
-- [Basic machine example](#basic-machine-example)
-- [Structure of more complex machines](#complex-machines-with-multiple-parts)
-
-{{<imgproc class="imgzoom" src="/architecture/architecture-diagram.svg" resize="x1100" declaredimensions=true alt="Viam-server runs on your machine and communicates with processes running on your machine, with the Viam Cloud, with API clients, and with other machines running viam-server." >}}
-
-## `viam-server` and `viam-micro-server`
-
-`viam-server` is the open-source executable binary that runs on your machine's SBC or other computer.
-
-`viam-server` does the following locally:
-
-- Runs drivers for your hardware
-- Runs motion planning and vision services
-- Runs {{< glossary_tooltip term_id="module" text="modules" >}}
-- Manages local connections between all these resources
-- Captures and stores data
-
-When `viam-server` can connect to the cloud, it also:
-
-- Automatically pulls configuration updates you make
-- Gets new versions of software packages
-- Uploads and syncs image and sensor data
-- Handles requests from client code you write with [SDKs](/reference/sdks/)
-- Allows you to remotely monitor and control your machine
-
-`viam-server` can use the internet, wide area networks (WAN) or local networks (LAN) to establish peer-to-peer connections between two {{< glossary_tooltip term_id="machine" text="machines" >}}, or to a client application.
-
-[`viam-micro-server`](/operate/reference/viam-micro-server/) is the lightweight version of `viam-server` that you can run on ESP32 microcontrollers.
-It supports a limited set of {{< glossary_tooltip term_id="resource" text="resources" >}} and can connect with the cloud as well as with devices running `viam-server`.
-
-## Components, services, modules
-
-A {{< glossary_tooltip term_id="component" text="component" >}} represents a physical piece of hardware in your {{< glossary_tooltip term_id="machine" text="machine" >}}, and the software that directly supports that hardware.
-
-A {{< glossary_tooltip term_id="service" text="service" >}} is a software package that adds complex capabilities such as motion planning or object detection to your machine.
-
-Viam has many built-in components and services that run within `viam-server`.
-
-A _modular resource_ is a custom component or service, not built into `viam-server` but rather provided by a _module_ that you or another user have created.
-A module runs as a process managed by `viam-server` on your machine, communicating over UNIX sockets, and `viam-server` manages its lifecycle.
-
-{{<imgproc src="/viam/machine-components.png" resize="x1100" declaredimensions=true alt="Machine structure" style="width:600px" >}}
-
-{{< expand "Click for an example" >}}
-
-Imagine you have a wheeled rover with two motors, a GPS unit, and a camera, controlled by a single-board computer (SBC) such as a Raspberry Pi.
-
-The motors, GPS, and camera each require software drivers so that the board can send signals to them and receive signals from them.
-These drivers are called _{{< glossary_tooltip term_id="component" text="components" >}}_.
-There is also a _component_ for the board itself that allows Viam software to communicate with the pins on the board.
-
-If you configure a [base component](/operate/reference/components/base/), you can specify the size of the wheels attached to the motors, and how wide the rover base is, so `viam-server` can calculate how to coordinate the motion of the rover base.
-
-If your rover includes a piece of hardware (such as a particular sensor) that is not yet supported as a built-in in by Viam, check the registry for a contributed {{< glossary_tooltip term_id="module" text="module" >}} or write your own module to integrate it into your machine.
-
-Say you want your machine to navigate intelligently between GPS coordinates.
-Instead of writing code from scratch, you can use Viam's built-in navigation service by adding it to your configuration, specifying how the GPS and any additional movement sensors are oriented with respect to your hardware.
-Since your configuration includes information about the wheeled base of your rover as well as how that base is oriented in relation to your GPS and other sensors, `viam-server` can use the motion and navigation services to calculate how much power to send to each motor to get it to a point on the map.
-
-If you want to add some other high-level software functionality beyond the built-in services (for example, your own flavor of navigation service), you can add your own service with a module.
-
-{{< /expand >}}
-
-## Communication
-
-<img src="https://assets-global.website-files.com/62fba5686b6d47fe2a1ed2a6/63334e5e19a68d329b1c5b0e_viam-overview-illustrations-manage.svg" alt="A diagram illustrating secure machine control." class="alignleft" style="width:270px;"></img>
-
-Viam uses peer-to-peer communication, where all machines running `viam-server` or [`viam-micro-server`](/operate/reference/viam-micro-server/) (the version of `viam-server` for microcontrollers) communicate directly with each other as well as with the cloud.
-This peer-to-peer connectivity is enabled by sending [gRPC commands over WebRTC connections](/operate/reference/architecture/machine-to-machine-comms/#low-level-inter-robotsdk-communication).
-
-On startup, `viam-server` establishes a {{< glossary_tooltip term_id="webrtc" text="WebRTC" >}} connection with Viam.
-`viam-server` pulls its configuration from the app, caches it locally, and initializes all components and services based on that configuration.
-
-If [sub-parts or remote parts](#complex-machines-with-multiple-parts) are configured, communications are established between the `viam-server` instances on each of them.
-
-If you have client code running on a separate computer, that code sends API requests to `viam-server` using gRPC over WebRTC.
-If a WebRTC connection cannot be established, the request is sent directly over gRPC.
-The Viam cloud works as the signaling server for connections where possible.
-If you are connecting to a machine over local network or in offline mode, `viam-server` functions as the signaling server instead.
-
-When a built-in service communicates with a component, for example when the vision service requests an image from a camera, `viam-server` handles that request as well.
-
-When you control your machine or view its camera streams or sensor outputs from the **CONTROL** tab, those connections happen over WebRTC.
-The web UI uses the same API endpoints as your SDK client code (in fact, it uses the Viam TypeScript SDK), with `viam-server` handling requests.
-
-{{% alert title="Protobuf APIs" color="info" %}}
-All Viam APIs are defined with the [Protocol Buffers (protobuf)](https://protobuf.dev/) framework.
-{{% /alert %}}
-
-For more details, see [Machine-to-Machine Communication](/operate/reference/architecture/machine-to-machine-comms/).
-
-### Security
-
-TLS certificates automatically provided by Viam ensure that all communication is authenticated and encrypted.
-
-Viam uses API keys with [role-based access control (RBAC)](/manage/manage/rbac/) to control access to machines from client code.
-
-## Data management flow
-
-{{<imgproc src="/architecture/data-flow.svg" resize="x1100" declaredimensions=true alt="Data flowing from local disk to cloud to Viam, SDKs, and MQL and SQL queries." >}}
-<br>
-
-Data is captured and synced to the Viam Cloud as follows:
-
-1. Data collected by your resources, such as sensors and cameras, is first stored locally in a specified directory (defaults to <file>~/.viam/capture</file>).
-   You control what data to capture, how often to capture it, and where to store it using the configuration.
-
-   - You can also sync data from other sources by putting it into folders you specify.
-     <br><br>
-
-1. `viam-server` syncs data to the cloud at your specified interval, and deletes the data from the local directory.
-
-1. You can view your data in the web UI or query it using Viam SDKs, MQL, or SQL.
-
-If a device has intermittent internet connectivity, data is stored locally until the machine can reconnect to the cloud.
-
-For more information, see [Data management service](/data/capture-sync/capture-and-sync-data/).
-
-## Basic machine example
-
-<p>
-{{<imgproc src="/architecture/simple-machine.png" class="alignright" resize="x1000" declaredimensions=true alt="viam-server running on a board connected to a sensor. Data is temporarily stored on a local folder until it is synced to Viam." style="width:400px" >}}
-</p>
-
-Imagine you have a simple device consisting of a temperature sensor connected to the GPIO pins of a single-board computer (SBC).
-You want to capture sensor data at regular intervals, and sync it to the cloud.
-Here is how this works in Viam:
-
-- You configure your machine in the web UI with a sensor {{< glossary_tooltip term_id="component" text="component" >}} and the data management {{< glossary_tooltip term_id="service" text="service" >}}.
-- `viam-server` runs on the SBC, managing all communications between hardware and the cloud using gRPC over {{< glossary_tooltip term_id="webrtc" text="WebRTC" >}}.
-  On startup, `viam-server` uses credentials stored locally to establish a connection with Viam and fetches its configuration.
-- Sensor data is cached in a local folder, then synced to the cloud at a configurable interval.
-- You can use the tools on Viam to remotely view sensor data as well as to change your machine's configuration, to view logs, and more.
-
-Now imagine you want to run code to turn on a fan when the temperature sensor reads over 100 degrees Fahrenheit:
-
-- Configure the fan motor as a motor component and wire the fan motor relay to the same board as the sensor.
-- Write your script using one of the Viam [SDKs](/reference/sdks/), for example the Viam Python SDK, using the sensor API and motor API.
-- You then run this code either locally on the SBC, or on a separate server.
-  See [Create a headless app](/operate/control/headless-app/) for more information.
-  Your code connects to the machine, authenticating with API keys, and uses the [sensor API](/operate/reference/components/sensor/#api) to get readings and the [motor API](/operate/reference/components/motor/#api) to turn the motor on and off.
-
-  {{< imgproc src="/build/program/sdks/robot-client.png" resize="x400" declaredimensions=true alt="A desktop computer (client in this case) sends commands to robot 1 (server) with gRPC over wifi." >}}
-
-Now, imagine you want to change to a different model of temperature sensor from a different brand:
-
-- You power down your device, disconnect the old sensor from your SBC and connect the new one.
-- You update your configuration in the web UI to indicate what model you are using, and how it's connected (imagine this one uses USB instead of GPIO pins).
-- You turn your device back on, and `viam-server` automatically fetches the config updates.
-- You do not need to change your control code, because the API is the same for all models of sensor.
-
-## Complex machines with multiple parts
-
-In Viam, a _{{< glossary_tooltip term_id="part" text="part" >}}_ is an organizational concept consisting of one instance of `viam-server` (or `viam-micro-server`) running on a SBC or other computer, and all the hardware and software that the `viam-server` instance controls.
-
-Many simple {{< glossary_tooltip term_id="machine" text="machines" >}} consist of only one part: just one computer running `viam-server` with configured components and services.
-If you have a more complex situation with multiple computers and associated hardware working together, you have two options for organization:
-
-- One complex {{< glossary_tooltip term_id="machine" text="machine" >}} consisting of multiple parts, working together.
-- Multiple individual machines (each made up of one or more parts), linked by a {{< glossary_tooltip term_id="remote-part" text="remote" >}} connection.
-
-These two options are very similar: in both cases, the parts communicate with each other securely and directly using gRPC/{{< glossary_tooltip term_id="webrtc" text="WebRTC" >}}.
-Any given part can be a remote part of multiple machines, whereas a part can only be a sub-part of one machine.
-In other words, remote connections allow sharing of resources across multiple machines, whereas main parts and sub-parts are a way to hierarchically organize one machine.
-
-Connecting parts (either as main part and sub-part, or as part and remote part) means that you can write control code that establishes a connection with the main part and controls all parts in a coordinated way.
-This streamlines authentication because you do not need to provide multiple sets of API keys as you would if you were using separate API clients.
-However, in some high-bandwidth cases it is better to establish a direct connection from an API client to a part, because connections to remotes and to sub-parts use the main part's bandwidth.
-
-{{< expand "Multi-part and remote examples" >}}
-
-- **Compute power example:** Imagine you have a robotic arm with a camera on it, connected to a SBC such as a Raspberry Pi.
-  You want to use the Viam motion service to control the arm, and you want to use the vision service on the output from the camera, but the SBC does not have the compute power to plan complex motion and also interpret camera output quickly.
-  You can set up a second {{< glossary_tooltip term_id="part" text="part" >}} on a server, as a sub-part of the same machine, and offload the heavy compute to that part.
-
-- **One weather station to many boats:** Imagine you have one weather station collecting data, and multiple boats (perhaps some in different {{< glossary_tooltip term_id="organization" text="organizations" >}}) whose behavior depends on that weather data.
-  You can set up a remote connection from each of the `viam-server` instances running on the boats to the `viam-server` instance on the weather station and get that data more directly, without having to wait for the data to sync to the cloud.
-
-- **One camera to many rovers:** Imagine you have a fleet of rovers in a factory.
-  One camera has an overhead view of the entire factory floor.
-  The camera is set up as one machine.
-  Each of the rovers is a separate machine, and they can each have the camera configured as a remote so that they can access the overhead camera stream.
-
-{{< /expand >}}
-
-See [Parts, Sub-parts and Remotes](/operate/reference/architecture/parts/) for more details.
-
-## Next steps
-
-This page has provided an overview of the architecture of just one machine.
-For information on organizing a fleet of many machines, see [Organize your machines](/manage/reference/organize/).
-
-For more details on the architecture of a single machine, see the following:
diff --git a/docs/operate/reference/architecture/machine-to-machine-comms.md b/docs/operate/reference/architecture/machine-to-machine-comms.md
deleted file mode 100644
index de33640719..0000000000
--- a/docs/operate/reference/architecture/machine-to-machine-comms.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: "Machine-to-Machine Communication: End-to-End Flow"
-linkTitle: "Machine-to-Machine Communication"
-weight: 60
-type: "docs"
-description: "Explanation of how a machine and its parts interact at the communication layer."
-aliases:
-  - /internals/robot-to-robot-comms/
-  - /internals/machine-to-machine-comms/
-  - /architecture/machine-to-machine-comms/
-toc_hide: true
----
-
-When building a smart machine application in, a user typically begins by configuring their machine which can consist of one or more {{< glossary_tooltip term_id="part" text="parts" >}}.
-Next they will test that it is wired up properly using the Control page.
-Once they've ensured everything is wired up properly, they will build their main application and the business logic for their machine using one of Viam's language SDKs.
-This SDK-based application is typically run on either the main part of the machine or a separate computer dedicated to running the business logic for the machine.
-
-Below, we describe the flow of information through a Viam-based multipart machine and then get into the specifics of what backs these connections and communications APIs.
-
-## High-level inter-robot/SDK communication
-
-To begin, let's define our machine's topology:
-
-![robot communication diagram](/internals/robot-to-robot-comms/robot-communication-diagram.png)
-
-This machine is made of two parts and a separate SDK-based application, which we'll assume is on a third machine, though it could just as easily run on the main part without any changes.
-
-- The first and main part, RDK Part 1, consists of a Raspberry Pi and a single USB connected camera called Camera.
-
-- The second and final part, RDK Part 2, consists of a Raspberry Pi connected to a robotic arm over ethernet and a gantry over GPIO.
-
-RDK Part 1 will establish a bidirectional gRPC/{{< glossary_tooltip term_id="webrtc" >}} connection to RDK Part 2.
-RDK Part 1 is considered the controlling peer (client).
-RDK Part 2 is consider the controlled peer (server).
-
-Let's suppose our SDK application uses the camera to track the largest object in the scene and instructs the arm to move to that same object.
-
-Since RDK Part 1 is the main part and has access to all other parts, the application will connect to it using the SDK.
-Once connected, it will take the following series of actions:
-
-<OL>
-<li>Get segmented point clouds from the camera and the object segmentation service.</li>
-
-<li>Find the largest object by volume.</li>
-
-<li>Take the object's center pose and tell the motion service to move the arm to that point.</li>
-
-<li>Go back to 1.</li>
-</OL>
-Let's breakdown how these steps are executed.
-
-<ol>
-<li>Get segmented point clouds from the camera and the object segmentation service:</li>
-
-![robot communication diagram](/internals/robot-to-robot-comms/getobjectpointcloud-flow.png)
-
-<OL type="a">
-<li>The SDK will send a GetObjectPointClouds request with Camera being referenced in the message to RDK Part 1's Object Segmentation Service.</li>
-
-<li>RDK Part 1 will look up the camera referenced, call the GetPointCloud method on it.</li>
-
-<li>The Camera will return the PointCloud data to RDK Part</li>
-
-<li>RDK Part 1 will use a point cloud segmentation algorithm to segment geometries in the PointCloud.</li>
-{{% alert title="Important" color="note" %}}
-The points returned are respective to the reference frame of the camera.
-This will become important in a moment.
-{{% /alert %}}
-<li>The set of segmented point clouds and their bounding geometries are sent back to the SDK-based application.</li>
-</ol>
-
-<li>Find the largest object by volume:</li>
-<ol type="a">
-<li>The application will iterate over the geometries of the segmented point clouds returned to it and find the object with the greatest volume and record its center pose.</li>
-</ol>
-
-<li>Take the object's center pose and tell the motion service to move the arm to that point:</li>
-
-![motion service move flow](/internals/robot-to-robot-comms/motion-service-move-flow.png)
-
-<ol type="a">
-<li>The SDK application will send a Move request for the arm to the motion service on RDK Part 1 with the destination set to the center point determined by the application.</li>
-
-<li>RDK Part 1's motion service will break down the Move request and perform the necessary frame transforms before sending the requests along to the relevant components.
-This is where the frame system comes into play.
-Our center pose came from the camera but we want to move the arm to that position even though the arm lives in its own frame.
-The frame system logic in the RDK automatically handles the transformation logic between these two reference frames while also handling understanding how the frame systems are connected across the two parts.</li>
-
-<li>Having computed the pose in the reference frame of the arm, the motion service takes this pose, and sends a plan on how to move the arm in addition to the gantry to achieve this new goal pose to RDK Part 2.
-The plan consists of a series of movements that combine inverse kinematics, mathematics, and constraints based motion planning to get the arm and gantry to their goal positions.</li>
-
-<li>In executing the plan, which is being coordinated on RDK Part 1, Part 1 will send messages to the Arm and Gantry on RDK Part 2.
-RDK Part 2 will be unaware of the actual plan and instead will only receive distinct messages to move the components individually.</li>
-
-<li>The arm and gantry connected to RDK Part 2 return an acknowledgement of the part Move requests to RDK Part 2.</li>
-
-<li>RDK Part 2 returns an acknowledgement of the Motion Move request to RDK Part 1.</li>
-
-<li>RDK Part 1 returns an acknowledgement of the Motion Move request to the SDK application.</li>
-</ol>
-<br>
-
-## Low-level inter-robot/SDK communication
-
-All component and service types in the RDK, and the Viam API for that matter, are represented as [Protocol Buffers (protobuf)](https://developers.google.com/protocol-buffers) services.
-protobuf is a battle tested Interface Description Language (IDL) that allows for specifying services, their methods, and the messages that comprise those methods.
-Code that uses protobuf is autogenerated and compiles messages into a binary form.
-
-[gRPC](https://grpc.io/) is responsible for the transport and communication of protobuf messages when calling protobuf methods.
-It generally works over a TCP, TLS backed HTTP2 connection operating over framing see [gRPC's HTTP2 documentation](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md) for more.
-
-The RDK uses protobuf and gRPC to enable access and control to its components and services.
-That means if there are two arms in a machine configuration, there is only one Arm service that handles the Remote Procedure Calls (RPC) for all arms configured.
-
-In addition to gRPC, the RDK uses [WebRTC](https://webrtcforthecurious.com/) video and audio streams and data channels to enable peer to peer (P2P) communication between machine parts as well as SDKs and the Remote Control interface.
-
-An outline of how WebRTC is used lives on [Go.dev](https://pkg.go.dev/go.viam.com/utils@v0.0.3/rpc#hdr-Connection), but in short, an RDK is always waiting on [app.viam.com](https://app.viam.com) to inform it of a connection requesting to be made to it whereby it sends details about itself and how to connect on a per connection basis.
-Once a connection is made, [app.viam.com](https://app.viam.com) is no longer involved in any packet transport and leaves it up to the two peers to communicate with each other.
-
-### Security implications
-
-Generally you do not need to open any ports or change your network configuration, if:
-
-- machines are on the internet and can successfully talk with `app.viam.com` and WebRTC works or
-- machines are on the same local network and mDNS and WebRTC are working
-
-If WebRTC is not available, you can communicate with `viam-server` over a gRPC connection.
-The default port is 8080 but you can configure another port in the [network settings](/manage/fleet/system-settings/#configure-bind-address-and-port).
diff --git a/docs/operate/reference/architecture/parts.md b/docs/operate/reference/architecture/parts.md
deleted file mode 100644
index f165560e29..0000000000
--- a/docs/operate/reference/architecture/parts.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: "Machine architecture: Parts"
-linkTitle: "Parts, sub-parts, remotes"
-weight: 40
-type: "docs"
-description: "Connect multiple machine parts to each other as sub-parts or remotes."
-tags: ["server", "components", "services"]
-aliases:
-  - /manage/parts-and-remotes/
-  - /build/configure/parts-and-remotes/
-  - /configure/parts/
-  - /build/configure/parts/
-  - /architecture/parts/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-When {{< glossary_tooltip term_id="machine" text="smart machines" >}} communicate with each other, they can share resources and operate collaboratively.
-This document explains how to establish secure connections between machines.
-
-## Machine parts
-
-Machines are organized into _parts_, where each part represents a computer (a single-board computer, desktop, laptop, or other computer) running [`viam-server`](/operate/reference/viam-server/), the hardware {{< glossary_tooltip term_id="component" text="components" >}} attached to it, and any {{< glossary_tooltip term_id="service" text="services" >}} or other {{< glossary_tooltip term_id="resource" text="resources" >}} running on it.
-
-Every smart machine has a main part which is automatically created when you create the machine.
-Multi-part machines also have one or more _sub-parts_ representing additional computers running `viam-server`.
-
-There are two ways to link machine parts:
-
-- **Sub-part**: If you have multiple computers within the _same machine_, use one as the main part and [connect each additional part to it as a sub-part](#configure-a-sub-part).
-  Any given part can only be a sub-part of one main part.
-
-  <details>
-    <summary>Click for an example.</summary>
-   Imagine you have a system of five cameras in different places along an assembly line, each attached to its own single-board computer, and you want to run an object detector on the streams from all of them.
-   You have one main computer with greater compute power set up as the main part.
-   You set up each of the single-board computers as a sub-part.
-   This allows the main part to access all the camera streams and run object detection on all of them.<br><br>
-   You could also set this up with each single-board computer being a remote part instead of a sub-part, but it is slightly easier to configure sub-parts because you do not need to add the address of each part to your machine's config.
-   Additionally, configuring a discrete system of parts as one multi-part machine helps keep your fleet more clearly organized.
-  </details><br>
-
-- **Remote part**: To connect multiple computers that are parts of _different machines_ in the same or different organizations, [add one machine part as a remote part of the other machine or machines](#configure-a-remote-part).
-  A part can be a remote part of any number of other parts.
-
-  <details>
-    <summary>Click for an example.</summary>
-    If you have one camera connected to a computer in a warehouse that many machines should be able to share, you can configure the camera as a remote part of each machine that needs it.
-  </details>
-
-Connections between machines are established using the best network path available.
-
-When you configure a remote part or a sub-part, the main machine part can access all the components and services configured on the remote machine part as though they were entities of the main machine part.
-This is a one-way connection: the main machine part can access the resources of the remote machine part, but the remote machine cannot access the resources of the machine part remoting into it.
-
-When a part starts up, it attempts to connect to any remotes and sub-parts.
-If it cannot connect to them, the part will still successfully start up.
-
-![Example of a remote and a two part machine where the main (and only) part of machine 1 remotes into the main part of machine 2, and thus has access to all resources of machine 2.](/build/configure/parts/remotes-diagram.png)
-
-### Find part ID
-
-To copy the ID of your machine part, select the part status dropdown to the right of your machine's location and name on the top of its page and click the copy icon next to **Part ID**.
-
-For example:
-
-{{<imgproc src="/build/program/data-client/grab-part-id.png" resize="1000x" class="shadow imgzoom" style="width: 500px" declaredimensions=true alt="Part ID displayed.">}}
-
-## Configuration
-
-### Configure a sub-part
-
-You can make a multi-part machine by first configuring one part which is the "main" part, and then configuring one or more sub-parts.
-The main part will be able to access the resources of its sub-parts.
-Sub-parts will _not_ have access to the resources of the main part.
-
-Viam automatically creates the main part for you when you create a new {{< glossary_tooltip term_id="machine" text="machine" >}}.
-To add a new sub-part:
-
-1. Navigate to the **CONFIGURE** tab of your machine's page.
-2. Click the **+** (Create) icon next to the name of your main part, then click **Sub-part** from the menu:
-
-   {{<imgproc src="/build/configure/parts/sub-part-config.png" resize="x1100" declaredimensions=true alt="The create part dropdown open." style="width:500px" class="shadow" >}}
-
-3. Save the config.
-
-{{% hiddencontent %}}
-The sub-part will not be visible as a `remote` in the debug config until after you use the setup instructions to make the sub-part go live.
-{{% /hiddencontent %}}
-
-To rename or delete a sub-part, or to make it the main part, click the **...** menu:
-
-{{<imgproc src="/build/configure/parts/part-mgmt.png" resize="x1100" declaredimensions=true alt="The part actions dropdown open. Options include rename, restart part, make main part, view setup instructions, view history, and delete part." style="width:500px" class="shadow" >}}
-
-By default, all sub-parts appear in the [frame system](/operate/reference/services/frame-system/) at the world origin.
-You can specify translations for sub-parts by configuring their frames with appropriate translation values relative to their parent frame.
-You can view the `frame` of each sub-part in the `remotes` section of the debug config.
-
-### Configure a remote part
-
-To establish a connection between a part of one machine and a part of a second machine, add one as a remote part in the other machine part's config:
-
-1. Go to the machine page of the machine part from which you want to establish a remote connection.
-   This is the machine part that will be able to access the resources of the other machine part.
-1. Navigate to the **CONFIGURE** tab, click the **+** (Create) icon next to the machine part's name in the left side menu.
-
-   {{<imgproc src="/build/configure/parts/remote-create.png" resize="x1100" declaredimensions=true alt="The create menu with options including remote part shown." style="width:500px" class="shadow" >}}
-
-1. Click **Remote part**.
-1. Select the remote part from the list of parts.
-
-   Alternatively, click **Add empty remote** and then scroll to the newly-created remote part configuration card.
-   Click on **JSON** and replace the JSON object with a remote config.
-
-   {{<imgproc src="/build/configure/parts/remote-config.png" resize="x1100" declaredimensions=true alt="The configured remote." style="width:700px" class="shadow" >}}
-
-   {{< expand "Click to see how to get a remote config object" >}}
-
-1. Go to the machine page of the smart machine part to which you wish to establish the remote connection.
-   This is the machine part whose resources will be accessible to the other machine part.
-1. Navigate to the **CONNECT** tab.
-1. Click **Configure as a remote part** in the left-hand menu.
-1. Copy the entire JSON snippet including the name, address, and authentication credentials of the remote part.
-
-   {{% snippet "show-secret.md" %}}
-
-   {{< /expand >}}
-
-   Remotes have the following parameters:
-
-   <!-- prettier-ignore -->
-   | Name               | Type   | Required? | Description |
-   | ------------------ | ------ | --------- | ----------- |
-   | `name` |  string | Optional | The name of the remote part. |
-   | `address` |  string | Optional | The address of the remote part. |
-   | `auth` | string | Object | The authentication credentials of the remote part. For example: `{ "credential": { "type": "api-key", "payload": "abcdefghijklmnop123456789abcdefg" } }`. |
-   | `prefix` | string | Optional | If set, all resource names fetched from the remote part have the prefix. For example, a component with the name `arm-1` configured on a remote part with the configuration `"prefix": "test123"` returns the name `test123arm-1`. |
-   | `notes` | string | Optional | Descriptive text to document the purpose, configuration details, or other important information about this remote part. |
-
-1. Click **Save** in the upper right corner of the page to save your config.
-
-## Using remote parts and sub-parts with the Viam SDKs
-
-Once your sub-part or remote part is configured, you can access all the components and services configured on the sub-part or remote machine part as though they were resources of your main machine part.
-The only difference is if the remote machine part has a configured prefix.
-If there is a prefix, you must prepend it to the resource name:
-
-For example, to access a servo called `my_servo` on a sub-part or a remote without configured `prefix`, you need to call:
-
-```python
-servo = Servo.from_robot(robot=robot, name='my_servo')
-```
-
-For a remote part with a `prefix` `my_remote`, instead use:
-
-```python
-servo = Servo.from_robot(robot=robot, name='my_remotemy_servo')
-```
diff --git a/docs/operate/reference/components/_index.md b/docs/operate/reference/components/_index.md
deleted file mode 100644
index 80fb4e2b50..0000000000
--- a/docs/operate/reference/components/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: "Components"
-linkTitle: "Components"
-weight: 20
-type: docs
-layout: "empty"
-canonical: "/operate/reference/components/arm/"
-no_component: true
-empty_node: true
-toc_hide: false
----
diff --git a/docs/operate/reference/components/arm/_index.md b/docs/operate/reference/components/arm/_index.md
deleted file mode 100644
index 998ead05be..0000000000
--- a/docs/operate/reference/components/arm/_index.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-title: "Arm Component"
-linkTitle: "Arm"
-childTitleEndOverwrite: "Arm Component"
-weight: 10
-type: "docs"
-description: "A robotic arm is made up of a series of links and joints, ending with a device you can position."
-no_list: true
-tags: ["arm", "components"]
-icon: true
-images: ["/icons/components/arm.svg"]
-modulescript: true
-aliases:
-  - /components/arm/
-hide_children: true
-outputs:
-  - html
-  - typesense
-date: "2024-10-21"
-# SME: Peter L
----
-
-The arm component provides an API for linear motion, including self-collision prevention.
-
-If you have a physical robotic arm, consisting of a serial chain of joints and links, with a fixed end and an end effector end, use an arm component.
-
-Arms have two ends: one fixed in place, and one with a device you can position.
-When controlling an arm, you can place its end effector at arbitrary cartesian positions relative to the base of the arm.
-
-## Configuration
-
-For an end-to-end guide that configures an arm and drives it through the motion service, see [Move your first arm](/motion-planning/quickstarts/first-arm/).
-
-To use a robotic arm, you need to add it to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your arm.
-
-The following list shows the available arm models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:arm" type="arm" no-intro="true">}}
-
-{{< alert title="Add support for other models" color="tip" >}}
-
-If none of the existing models fit your use case, you can create a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}} to add support for it.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [arm API](/reference/apis/components/arm/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/arm-table.md" >}}
-
-## Motion planning with your arm
-
-The arm API sends requests for the arm to move to a set of joint positions, and reports the arm's current joint positions.
-Viam's motion service provides an [API for moving the end of the arm to a given position, around any obstacles](/operate/reference/services/motion/#api).
-
-For each arm model, there is a JSON file that describes the [kinematics parameters of the arm](/operate/reference/kinematic-chain-config/).
-When you configure an arm model, the arm driver parses the kinematics file for the [frame system](/operate/reference/services/frame-system/) service to use.
-The frame system allows the motion service to calculate where any component of your machine is relative to any other component, other machine, or object in the environment.
-
-## Troubleshooting
-
-If your arm is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your arm model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the arm there.
-1. Disconnect and reconnect your arm.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/headless-app/" noimage="true" %}}
-{{% card link="/motion-planning/move-an-arm/move-to-pose/" noimage="true" %}}
-{{< /cards >}}
-
-You can also use the arm component with the following services:
-
-- [Motion service](/operate/reference/services/slam/): To move machines or components of machines
-- [Frame system service](/operate/reference/services/navigation/): To configure the positions of your components
diff --git a/docs/operate/reference/components/arm/eva.md b/docs/operate/reference/components/arm/eva.md
deleted file mode 100644
index ab206b471e..0000000000
--- a/docs/operate/reference/components/arm/eva.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: "Configure an Eva Arm"
-linkTitle: "eva"
-weight: 34
-type: "docs"
-draft: "true"
-description: "Configure an Eva arm."
-images: ["/icons/components/arm.svg"]
-tags: ["arm", "components"]
-aliases:
-  - "/components/arm/eva/"
-toc_hide: true
-# SMEs: Bucket, Motion
----
-
-Configure an `eva` arm to integrate an [Automata Eva](https://automata.tech/products/hardware/about-eva/) robotic arm into your machine.
-
-If you want to test your arm as you configure it, connect it to your machine's computer and turn it on.
-Then, configure the arm:
-
-{{< tabs name="Configure an eva Arm" >}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<arm_name>",
-  "model": "eva",
-  "api": "rdk:component:arm",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< readfile "/static/include/components/test-control/arm-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/arm.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/arm/" customTitle="Arm API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/motion-planning/move-an-arm/move-to-pose/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/arm/fake.md b/docs/operate/reference/components/arm/fake.md
deleted file mode 100644
index 3e4c743340..0000000000
--- a/docs/operate/reference/components/arm/fake.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: "Configure a Fake Arm"
-linkTitle: "fake"
-weight: 34
-type: "docs"
-description: "Configure a fake arm to use for testing."
-images: ["/icons/components/arm.svg"]
-tags: ["arm", "components"]
-aliases:
-  - "/components/arm/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
-# SMEs: Bucket, Motion
----
-
-Configure a `fake` arm to test different models of robotic arms without any physical hardware:
-
-{{< tabs name="Configure a Fake Arm" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `arm` type, then select the `fake` model.
-Enter a name or use the suggested name for your arm and click **Create**.
-
-![An example configuration for a fake ur5e arm.](/components/arm/fake-arm-ui-config.png)
-
-Fill in the attributes as applicable to your arm, according to the table below.
-
-{{% alert title="Important" color="note" %}}
-
-Only one of these attributes can be supplied for your `fake` arm to work.
-If neither are specified, a fake arm model with 1 degree-of-freedom will be used.
-If both attributes are specified, an error is thrown stating "can only populate either ArmModel or ModelPath - not both".
-
-{{% /alert %}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<arm_name>",
-  "model": "fake",
-  "api": "rdk:component:arm",
-  "attributes": {
-    "arm-model": "<your_arm_model>",
-    "model-path": "<path_to_arm_model>"
-  },
-  "depends_on": []
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "my-fake-arm",
-  "model": "fake",
-  "api": "rdk:component:arm",
-  "attributes": {
-    "arm-model": "ur5e"
-  },
-  "depends_on": []
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `fake` arms:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `arm-model` | string | Optional | Model name of the robotic arm model you want your fake arm to act as. See [built-in arm models](../#configuration) for supported model names. |
-| `model-path` | string | Optional | The path to the [kinematic configuration file](/operate/reference/kinematic-chain-config/) of the arm driver you want your fake arm to act as. This path should point to the exact location where the file is located on your computer running `viam-server`. |
-
-{{< readfile "/static/include/components/test-control/arm-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/arm.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/arm/" customTitle="Arm API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/motion-planning/move-an-arm/move-to-pose/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/arm/yahboom-dofbot.md b/docs/operate/reference/components/arm/yahboom-dofbot.md
deleted file mode 100644
index 2609835212..0000000000
--- a/docs/operate/reference/components/arm/yahboom-dofbot.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: "Configure a Yahboom DOFBOT Arm"
-linkTitle: "yahboom-dofbot"
-weight: 50
-type: "docs"
-draft: "true"
-description: "Configure a Yahboom DOFBOT modular arm."
-images: ["/icons/components/arm.svg"]
-tags: ["arm", "components"]
-aliases:
-  - "/components/arm/yahboom-dofbot/"
-toc_hide: true
----
-
-Viam supports the [Yahboom DOFBOT](https://category.yahboom.net/collections/r-robotics-arm) arm as a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}}.
-You can explore the source code on the [Viam-labs Yahboom GitHub repository](https://github.com/viam-labs/yahboom).
-
-Configure a `dofbot` arm to add it to your machine.
-
-If you want to test your arm as you configure it, connect it to your machine's computer and turn it on.
-Then, configure the arm:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `arm` type, then select the `rand:yahboom:dofbot` modular resource.
-Enter a name or use the suggested name for your arm and click **Create**.
-
-There are no attributes available for this modular arm.
-
-<!-- ![Web UI configuration panel for an arm of model yahboom-dofbot, with Attributes & Depends On dropdowns and the option to add a frame.](/components/arm/yahboom-dofbot-ui-config.png) -->
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-arm-name>",
-      "model": "dofbot",
-      "api": "rdk:component:arm",
-      "attributes": {},
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "myarm",
-      "model": "yahboom-dofbot",
-      "api": "rdk:component:arm",
-      "attributes": {},
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< readfile "/static/include/components/test-control/arm-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/arm.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/arm/" customTitle="Arm API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/motion-planning/move-an-arm/move-to-pose/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/base/_index.md b/docs/operate/reference/components/base/_index.md
deleted file mode 100644
index 390e15aa78..0000000000
--- a/docs/operate/reference/components/base/_index.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: "Base Component"
-linkTitle: "Base"
-weight: 14
-type: "docs"
-no_list: true
-description: "The base component allows you to move a mobile robot without needing to send commands to individual components like motors."
-tags: ["base", "components"]
-icon: true
-images: ["/icons/components/base.svg"]
-modulescript: true
-aliases:
-  - "/components/base/"
-  - "/micro-rdk/base/"
-  - "/build/micro-rdk/base/"
-hide_children: true
-date: "2024-10-21"
-# SMEs: Steve B
----
-
-The base component provides an API for moving all configured drive motors of a mobile robot platform as a whole without needing to send commands to individual motor components.
-
-If you have a mobile robot, use a base component to coordinate the motion of its motor components.
-
-<p>
-<img src="/components/base/base-trk-rover-w-arm.png" alt="A robot comprised of a wheeled base (motors, wheels and chassis) as well as some other components. The wheels are highlighted to indicate that they are part of the concept of a 'base', while the non-base components are not highlighted. The width and circumference are required attributes when configuring a base component." class="imgzoom aligncenter" style="width: 550px">
-</p>
-
-## Configuration
-
-Most mobile robots with a base use the following hardware:
-
-- Some actuators to move the base, such as [motors](/operate/reference/components/motor/) attached to wheels or propellers
-- Some sort of chassis to hold everything together
-
-To use a rover or other base, you need to add each component as well as the base to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your base.
-
-The following list shows the available base models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:base" type="base" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`two_wheeled_base`](two_wheeled_base/) | Mobile robot with two wheels |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [base API](/reference/apis/components/base/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/base-table.md" >}}
-
-## Troubleshooting
-
-If your base is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your base model's documentation to ensure you have configured all required attributes.
-1. Review your configuration for any motors that are components of the base.
-   Check that the names of the motor components match the list of motors you configured on the base.
-1. If a motor is spinning in an unexpected direction, try using the `dir_flip` attribute in its config, or try swapping the wires running to the motor to change its direction.
-1. Check that all wires are securely attached to the correct pins.
-1. If you are using a battery to power the base, check that it is adequately charged.
-   If the motors are drawing more power than the battery can supply, the single-board computer may be power cycling.
-   Consider using a wall power supply for testing purposes to rule out this issue.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the base there.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/tutorials/configure/configure-rover/" noimage="true" %}}
-{{% card link="/tutorials/control/drive-rover/" noimage="true" %}}
-{{< /cards >}}
-
-You can also use the base component with the following services:
-
-- [Navigation service](/operate/reference/services/navigation/): to navigate with GPS
-- [SLAM service](/operate/reference/services/slam/): for mapping
diff --git a/docs/operate/reference/components/base/boat.md b/docs/operate/reference/components/base/boat.md
deleted file mode 100644
index f2149b14bf..0000000000
--- a/docs/operate/reference/components/base/boat.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: "Configure a Boat Base"
-linkTitle: "boat"
-weight: 35
-type: "docs"
-draft: "true"
-description: "Configure a boat base."
-images: ["/icons/components/base.svg"]
-tags: ["base", "components"]
-aliases:
-  - "/components/base/boat/"
-toc_hide: true
-# SMEs: Eliot
----
-
-A `boat` base is a model for a mobile robotic boat.
-To configure a `boat` base as a component of your machine, first configure the [board](/operate/reference/components/board/) controlling the base and any [motors](/operate/reference/components/motor/) attached to the base.
-
-{{< tabs name="Configure a Boat Base" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `base` type, then select the `boat` model.
-Enter a name or use the suggested name for your base and click **Create**.
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "base",
-      "model": "boat",
-      "api": "rdk:component:base",
-      "attributes": {
-        "drive_mode": "<a_drive_mode_option>",
-        "serial_path": "</dev/ttyXXXX>"
-      },
-      "depends_on": []
-    }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `boat` bases:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `length_mm` | int | **Required** | Length of the base in millimeters. In other words, the distance between the approximate centers of the right and left wheels. Can be an approximation. |
-| `width_mm` | int | **Required** | Width of the base in millimeters. In other words, the distance between the approximate centers of the right and left motors. Can be an approximation. |
-| `IMU` | string | **Required** | Name of the [Inertial Measurement Unit](/reference/apis/components/movement-sensor/#imu-configuration) in the boat. |
-| `Motors` | string[] | **Required** | JSON struct containing the configuration attributes for each motor attached to the boat. |
-
-Each [motor](/operate/reference/components/motor/) inside of `Motors` has the following attributes available:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `Name` | string | **Required** | Name of the motor. |
-| `x_offset_mm` | int | **Required** | |
-| `y_offset_mm` | int | **Required** | |
-| `angle_degs` | int | **Required** | |
-| `Weight` | int | **Required** | |
-
-## Test the base
-
-{{< readfile "/static/include/components/test-control/base-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/base.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/base/" customTitle="Base API" noimage="true" %}}
-{{% card link="/tutorials/configure/configure-rover/" noimage="true" %}}
-{{% card link="/tutorials/control/drive-rover/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/base/fake.md b/docs/operate/reference/components/base/fake.md
deleted file mode 100644
index cb60e84719..0000000000
--- a/docs/operate/reference/components/base/fake.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: "Configure a Fake Base"
-linkTitle: "fake"
-weight: 20
-type: "docs"
-description: "Configure a fake base to use for testing without physical hardware."
-images: ["/icons/components/base.svg"]
-tags: ["base", "components"]
-aliases:
-  - "/components/base/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
-# SMEs: Steve B
----
-
-Configure a `fake` base to test implementing a base component on your machine without any physical hardware:
-
-{{< tabs name="Configure a Fake Base" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `base` type, then select the `fake` model.
-Enter a name or use the suggested name for your base and click **Create**.
-
-{{< imgproc src="/components/base/fake-base-ui-config.png" alt="An example configuration for a fake base." resize="1200x" style="width: 900px" class="shadow" >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-base-name>",
-  "api": "rdk:component:base",
-  "model": "fake",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for `fake` bases.
-See [GitHub](https://github.com/viamrobotics/rdk/blob/main/components/base/fake/fake.go) for API call return specifications.
-
-## Test the base
-
-{{< readfile "/static/include/components/test-control/base-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/base.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/base/" customTitle="Base API" noimage="true" %}}
-{{% card link="/tutorials/configure/configure-rover/" noimage="true" %}}
-{{% card link="/tutorials/control/drive-rover/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/base/sensor-controlled.md b/docs/operate/reference/components/base/sensor-controlled.md
deleted file mode 100644
index 31665728f8..0000000000
--- a/docs/operate/reference/components/base/sensor-controlled.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: "Configure a Sensor-Controlled Base"
-linkTitle: "sensor-controlled"
-weight: 40
-type: "docs"
-description: "Configure a sensor-controlled base, a robotic base with feedback control from a movement sensor."
-images: ["/icons/components/base.svg"]
-tags: ["base", "components"]
-aliases:
-  - "/components/base/sensor-controlled/"
-component_description: "Wrap other base models and add feedback control using a movement sensor."
-toc_hide: true
-# SMEs: Rand H., Martha J.
----
-
-A `sensor-controlled` base supports a robotic base with feedback control from a movement sensor.
-
-{{% alert title="Requirements" color="note" %}}
-In order to use feedback control, you must provide a movement sensor that implements [AngularVelocity()](/reference/apis/components/movement-sensor/#getangularvelocity) and [LinearVelocity()](/reference/apis/components/movement-sensor/#getlinearvelocity). This will enable feedback control for [SetVelocity()](/reference/apis/components/base/#setvelocity).
-
-In order to use feedback control for [Spin()](/reference/apis/components/base/#spin), you must also provide a movement sensor that implements [Orientation()](/reference/apis/components/movement-sensor/#getorientation).
-
-In order to use feedback control for [MoveStraight()](/reference/apis/components/base/#spin), you must also provide a movement sensor that implements [Position()](/reference/apis/components/movement-sensor/#getposition).
-Additionally, heading feedback control while moving straight can be used by providing a movement sensor that implements [Orientation()](/reference/apis/components/movement-sensor/#getorientation) or [CompassHeading()](/reference/apis/components/movement-sensor/#getcompassheading).
-{{% /alert %}}
-
-To configure a `sensor-controlled` base as a component of your machine, first configure the [model of base](/operate/reference/components/base/) you want to wrap with feedback control and each required [movement sensor](/operate/reference/components/movement-sensor/).
-To see what models of movement sensor report which feedback, reference the appropriate column in [Movement Sensor API](/reference/apis/components/movement-sensor/#api).
-
-Configure a `sensor-controlled` base as follows:
-
-{{< tabs name="Configure a Sensor-Controlled Base" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `base` type, then select the `sensor-controlled` model.
-Enter a name or use the suggested name for your base and click **Create**.
-
-{{< imgproc src="/components/base/sensor-controlled-base-ui-config.png" alt="An example configuration for a sensor-controlled base" resize="1200x" style="width: 600x" class="shadow" >}}
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    { ... INSERT MOVEMENT SENSOR CONFIGURATION },
-    { ... INSERT BASE CONFIGURATION },
-    {
-      "name": "my-sensor-controlled-base",
-      "model": "sensor-controlled",
-      "api": "rdk:component:base",
-      "attributes": {
-        "movement_sensor": [
-          "<your-orientation-or-velocity-movement-sensor-1>",
-          "<your-orientation-or-velocity-movement-sensor-2>"
-        ],
-        "base": "<your-base>"
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `sensor-controlled` bases:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `movement_sensor` | array | **Required** | Array with the `name`s of any movement sensors on your base you want to gather feedback from. The driver will select the first movement sensor providing appropriate feedback for either the `SetVelocity()` or the `Spin()` endpoint. <br> If your sensor has an adjustable frequency or period, set the frequency to something greater than or equal to the `control_frequency_hz`. A higher frequency will generally result in more stable behavior because the base control loop that adjusts the machine's behavior runs more frequently. |
-| `base` | string | **Required** | String with the `name` of the base you want to wrap with sensor control. |
-| `control_parameters` | object | Optional | A JSON object containing the coefficients for the proportional, integral, and derivative terms for linear and angular velocity. If you want these values to be auto-tuned, you can set all values to 0: `[ { "type": "linear_velocity", "p": 0, "i": 0, "d": 0 }, { "type": "angular_velocity", "p": 0, "i": 0, "d": 0 } ]`, and `viam-server` will auto-tune and log the calculated values. Tuning takes several seconds and spins the motors. Copy the values from the logs and add them to the configuration once tuned for the values to take effect. If you need to auto-tune multiple controlled components that depend on the same hardware, such as a sensor controlled base and one of the motors on the base, run the auto-tuning process one component at a time. For more information see [Feedback control](#feedback-control). |
-| `control_frequency_hz` | float | Optional | Adjusts the frequency that the base control loop runs at. A higher frequency will generally result in more stable behavior because the base control loop that adjusts the machine's behavior runs more frequently, provided the movement sensors can support the higher frequency. The default base control loop frequency is 10Hz. |
-
-## Feedback control
-
-### SetVelocity
-
-{{< readfile "/static/include/components/base-sensor.md" >}}
-
-### Spin
-
-When the `control_parameters` attribute is set, `Spin` implements a form of feedback control that polls the provided movement sensor and corrects any error between the desired angular velocity and the actual angular velocity using a PID control loop. `Spin` also monitors the angular distance traveled and stops the base when the goal angle is reached.
-
-### MoveStraight
-
-When `control_parameters` is set, `MoveStraight` calculates the required velocity to reach the desired velocity and distance. It then polls the provided velocity movement sensor and corrects any error between this calculated velocity and the actual velocity using a PID control loop. `MoveStraight` also monitors the position and stops the base when the goal distance is reached. If a compass heading movement sensor is provided, `MoveStraight` will attempt to keep the heading of the base fixed in the original direction it was faced at the beginning of the `MoveStraight` call.
-
-## Test the base
-
-{{< readfile "/static/include/components/test-control/base-control.md" >}}
-
-The following base control API methods are available on a `sensor-controlled` base:
-
-- [SetVelocity()](/reference/apis/components/base/#setvelocity): available if base is configured to receive angular and linear velocity feedback.
-- [Spin()](/reference/apis/components/base/#spin): available if base is configured to receive orientation feedback.
-- [MoveStraight()](/reference/apis/components/base/#movestraight): available if base is configured to receive position feedback.
-
-For example, a rover using `sensor-controlled` base following both an [angular](/reference/apis/components/base/#spin) and [linear](/reference/apis/components/base/#movestraight) velocity command:
-
-{{<gif webm_src="/components/encoded-motor/base_moving.webm" mp4_src="/components/encoded-motor/base-moving.mp4" alt="A Viam rover turning in a half circle" max-width="400px" >}}
-
-The position, orientation, and linear and angular velocity of the rover changing as it moves, as measured by a [movement sensor](/operate/reference/components/movement-sensor/):
-
-{{<gif webm_src="/components/encoded-motor/controls_change.webm" mp4_src="/components/encoded-motor/controls_change.mp4" alt="The control tab of a movement sensor on a base with encoded motors as it turns">}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/base.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/base/" customTitle="Base API" noimage="true" %}}
-{{% card link="/tutorials/configure/configure-rover/" noimage="true" %}}
-{{% card link="/tutorials/control/drive-rover/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/base/two_wheeled_base.md b/docs/operate/reference/components/base/two_wheeled_base.md
deleted file mode 100644
index a2c7591677..0000000000
--- a/docs/operate/reference/components/base/two_wheeled_base.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: "Configure a Two-Wheeled Base (Micro-RDK)"
-linkTitle: "two_wheeled_base (Micro-RDK)"
-weight: 30
-type: "docs"
-description: "Configure and wire a two-wheeled base with a microcontroller."
-images: ["/icons/components/base.svg"]
-tags: ["base", "components"]
-aliases:
-  - /micro-rdk/base/esp32_wheeled_base/
-  - /build/micro-rdk/base/esp32_wheeled_base/
-  - /build/micro-rdk/base/two_wheeled_base/
-  - /components/base/two_wheeled_base/
-micrordk_component: true
-toc_hide: true
-# SMEs: Gautham V.
----
-
-A `two_wheeled_base` base supports mobile robotic bases with drive motors on both sides (differential steering).
-Only bases with two drive wheels are supported by this `viam-micro-server` model.
-
-{{< alert title="Info" color="info" >}}
-
-The`two_wheeled_base` base model is not currently available when configuring your machine using **Builder** mode.
-
-{{< /alert >}}
-
-If you want to test your base as you configure it, physically assemble the base, connect it to your machine's computer, and turn it on.
-Then, configure a `two_wheeled_base` base as follows:
-
-{{< tabs name="Configure a Wheeled Base" >}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-base-name>",
-      "model": "two_wheeled_base",
-      "api": "rdk:component:base",
-      "attributes": {
-        "left": "<your-left-motor-name>",
-        "right": "<your-right-motor-name>"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "my-wheeled-base",
-      "model": "two_wheeled_base",
-      "api": "rdk:component:base",
-      "attributes": {
-        "left": "leftm",
-        "right": "rightm"
-      },
-      "depends_on": []
-    }, ... <INSERT LEFT AND RIGHT MOTOR CONFIGS>
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `two_wheeled_base` bases:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `left` | string | **Required** | The `name` of a drive motor on the left side of the base. |
-| `right` | string | **Required** | The `name` of a drive motor on the right side of the base. |
-
-## Test the base
-
-{{< readfile "/static/include/components/test-control/base-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/base.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/base/" customTitle="Base API" noimage="true" %}}
-{{% card link="/tutorials/configure/configure-rover/" noimage="true" %}}
-{{% card link="/tutorials/control/drive-rover/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/base/wheeled.md b/docs/operate/reference/components/base/wheeled.md
deleted file mode 100644
index 18cd49495e..0000000000
--- a/docs/operate/reference/components/base/wheeled.md
+++ /dev/null
@@ -1,168 +0,0 @@
----
-title: "Configure a Wheeled Base"
-linkTitle: "wheeled"
-weight: 30
-type: "docs"
-description: "Configure and wire a wheeled base."
-images: ["/icons/components/base.svg"]
-tags: ["base", "components"]
-aliases:
-  - "/components/base/wheeled/"
-component_description: "Supports mobile wheeled robotic bases with motors on both sides for differential steering."
-toc_hide: true
-# SMEs: Steve B
----
-
-A `wheeled` base supports mobile robotic bases with motors on both sides (differential steering).
-To configure a `wheeled` base as a component of your machine, first configure the [board](/operate/reference/components/board/) controlling the base and any [motors](/operate/reference/components/motor/) attached to the base.
-
-If you want to test your base as you configure it, physically assemble the base, connect it to your machine's computer, and turn it on.
-Then, configure a `wheeled` base as follows:
-
-{{< tabs name="Configure a Wheeled Base" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `base` type, then select the `wheeled` model.
-Enter a name or use the suggested name for your base and click **Create**.
-
-{{< imgproc src="/components/base/wheeled-base-ui-config.png" alt="An example configuration for a wheeled base, with Attributes & Depends On dropdowns and the option to add a frame." resize="1200x" style="width: 900px" class="shadow" >}}
-
-Select the motors attached to the base as your **right** and **left** motors.
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      ... <INSERT YOUR BOARD COMPONENT CONFIGURATION>
-    },
-    {
-      ... <INSERT YOUR LEFT MOTOR COMPONENT CONFIGURATION>
-    },
-    {
-      ... <INSERT YOUR RIGHT MOTOR COMPONENT CONFIGURATION>
-    },
-    {
-      "name": "<your-base-name>",
-      "model": "wheeled",
-      "api": "rdk:component:base",
-      "attributes": {
-        "left": [
-          "<your-left-motor-name>" // <INSERT ANY ADDITIONAL LEFT MOTOR NAMES>
-        ],
-        "right": [
-          "<your-right-motor-name>" // <INSERT ANY ADDITIONAL RIGHT MOTOR NAMES>
-        ],
-        "wheel_circumference_mm": <int>,
-        "width_mm": <int>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "my-pi",
-      "model": "pi",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": []
-    },
-    {
-      "name": "rightm",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "pins": {
-          "dir": "16",
-          "pwm": "15"
-        },
-        "board": "my-pi"
-      },
-      "depends_on": []
-    },
-    {
-      "name": "leftm",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "pins": {
-          "dir": "13",
-          "pwm": "11"
-        },
-        "board": "my-pi"
-      },
-      "depends_on": []
-    },
-    {
-      "name": "my-wheeled-base",
-      "model": "wheeled",
-      "api": "rdk:component:base",
-      "attributes": {
-        "width_mm": 195,
-        "wheel_circumference_mm": 183,
-        "left": ["leftm"],
-        "right": ["rightm"]
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Annotated JSON" %}}
-
-{{< imgproc src="/components/base/base-json.png" alt="JSON configuration file for a wheeled base with annotations explaining some of the attributes." resize="600x" class="shadow" >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `wheeled` bases:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `left` | array | **Required** | Array with the `name` of any drive motors on the left side of the base. |
-| `right` | array | **Required** | Array with the `name` of any drive motors on the right side of the base. |
-| `wheel_circumference_mm` | int | **Required** | The outermost circumference of the drive wheels in millimeters. Used for odometry. Can be an approximation. |
-| `width_mm` | int | **Required** | Width of the base in millimeters. In other words, the distance between the approximate centers of the right and left wheels. Can be an approximation. |
-| `spin_slip_factor` | float | Optional | Can be used in steering calculations to correct for slippage between the wheels and the floor. If used, calibrated by the user. |
-
-## Wire a `wheeled` base
-
-An example wiring diagram for a base with one motor on each side:
-
-![Wiring diagram showing a Raspberry Pi, motor drivers, motors, power supply, and voltage regulator for the rover](/components/base/base-wiring-diagram.png)
-
-Note that your base's wiring will vary depending on your choice of board, motors, motor drivers, and power supply.
-
-## Test the base
-
-{{< readfile "/static/include/components/test-control/base-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/base.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/base/" customTitle="Base API" noimage="true" %}}
-{{% card link="/tutorials/configure/configure-rover/" noimage="true" %}}
-{{% card link="/tutorials/control/drive-rover/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/board/_index.md b/docs/operate/reference/components/board/_index.md
deleted file mode 100644
index 0741054b46..0000000000
--- a/docs/operate/reference/components/board/_index.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: "Board Component"
-linkTitle: "Board"
-childTitleEndOverwrite: "Board Component"
-weight: 17
-type: "docs"
-no_list: true
-description: "The signal wire hub of a machine, with GPIO pins for transmitting signals between the machine's computer and its other components."
-tags: ["board", "components"]
-icon: true
-images: ["/icons/components/board.svg"]
-modulescript: true
-aliases:
-  - "/components/board/"
-  - "/micro-rdk/board/"
-  - "/build/micro-rdk/board/"
-hide_children: true
-date: "2024-10-21"
-# SMEs: Gautham, Rand
----
-
-The board component provides an API for setting GPIO pins to high or low, setting PWM, and working with analog and digital interrupts.
-
-If you have GPIO pins you wish to control, use a board component.
-
-Your GPIO pins can be present as:
-
-- The GPIO pins on a single-board computer (SBC).
-- A GPIO peripheral device that must connect to an external computer.
-- A PWM peripheral device that must connect to an SBC that has a CPU and GPIO pins.
-
-In other words, the board of a machine is its signal wire hub.
-Signaling controls the flow of electricity to these pins to change their state between "high" (active) and "low" (inactive), and to send [digital signals](https://en.wikipedia.org/wiki/Digital_signal) to and from other hardware.
-
-{{< alert title="Running viam-server" color="note" >}}
-
-The board component allows you to use the pins on your board.
-If there is no board model for your board:
-
-- you can still run `viam-server` if your board [supports it](/operate/install/setup/)
-- you can still access USB ports
-
-{{< /alert >}}
-
-## Configuration
-
-To use GPIO pins, you need to add a board component to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your board.
-
-The following list shows the available board models.
-If your board is not among them, you may be able to use the pins on your board with an experimental [periph.io](https://periph.io/)-based [modular component](https://github.com/viam-labs/periph_board).
-This works for boards such as the [RockPi S](https://wiki.radxa.com/RockpiS).
-
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:board" type="board" no-intro="true">}}
-
-{{< alert title="Add support for other models" color="tip" >}}
-If none of the existing models fit your use case, you can [create a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}}](/operate/modules/write-a-driver-module/) to add support for it.
-
-For Linux boards like the Odroid C4, Pumpkin, or, Banana Pi, you can also use the [`customlinux` board](https://github.com/viam-modules/customlinux/blob/main/README.md).
-{{< /alert >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`esp32`](esp32/) | An ESP32 microcontroller |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [board API](/reference/apis/components/board/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/board-table.md" >}}
-
-## Troubleshooting
-
-If your board is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your board model's documentation to ensure you have configured all required attributes.
-1. Check that all wires are securely connected.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the board there.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/tutorials/get-started/blink-an-led" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/board/esp32.md b/docs/operate/reference/components/board/esp32.md
deleted file mode 100644
index b5a097686d..0000000000
--- a/docs/operate/reference/components/board/esp32.md
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: "Configure an ESP32 Board (Micro-RDK)"
-linkTitle: "esp32 (Micro-RDK)"
-weight: 20
-type: "docs"
-description: "Configure an ESP32 board running viam-micro-server."
-images: ["/installation/thumbnails/esp32-espressif.png"]
-imageAlt: "E S P 32 - espressif"
-tags: ["board", "components"]
-aliases:
-  - /micro-rdk/board/esp32/
-  - /build/micro-rdk/board/esp32/
-  - /components/board/esp32/
-micrordk_component: true
-toc_hide: true
-# SMEs: Gautham, Nico, Andrew
----
-
-{{% alert title="REQUIREMENTS" color="caution" %}}
-
-Follow the [setup guide](/operate/install/setup/) to install and run `viam-micro-server` before configuring an `esp32` board.
-
-Viam recommends purchasing the ESP32 with a development board.
-The following ESP32 microcontrollers are supported:
-
-- ESP-32-WROVER Series
-
-Your microcontroller should have at least the following resources available to work with `viam-micro-server`:
-
-- 2 Cores + 384kB SRAM + 2MB PSRAM + 8MB Flash
-
-{{% /alert %}}
-
-To test your board as you configure it, power it on.
-If you plan to connect hardware to the board's pins, connect the hardware while it's powered off.
-To configure an `esp32` board, navigate to the **CONFIGURE** tab of your machine's page and select **JSON** mode.
-
-{{< alert title="Info" color="info" >}}
-
-The`esp32` [board](/operate/reference/components/board/) model is not currently available when configuring your machine using **Builder** mode.
-
-{{< /alert >}}
-
-Copy the following JSON template and paste it into your configuration inside the `"components"` array:
-
-{{< tabs name="Configure an esp32 Board" >}}
-{{% tab name="JSON Template"%}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-board-name>",
-  "model": "esp32",
-  "api": "rdk:component:board",
-  "attributes": {
-    "pins": [
-      <int>
-    ],
-    "analogs": [
-      {
-        "pin": <int>,
-        "name": "<your-analog-name>"
-      }
-    ],
-    "digital_interrupts" : [
-        {
-         "pin": <int>
-        }
-    ]
-  },
-  "depends_on": []
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "board",
-  "model": "esp32",
-  "api": "rdk:component:board",
-  "attributes": {
-    "pins": [15, 34],
-    "analogs": [
-      {
-        "pin": "34",
-        "name": "sensor"
-      }
-    ],
-    "digital_interrupts": [
-      {
-        "pin": 4
-      }
-    ]
-  },
-  "depends_on": []
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Edit and fill in the attributes as applicable.
-Click the **Save** button in the top right corner of the page.
-
-The following attributes are available for `esp32` boards:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `analogs` | array | Optional | Attributes of any pins that can be used as analog-to-digital converter (ADC) inputs. See [configuration info](#analogs). |
-| `i2cs` | array | Optional | Any Inter-Integrated Circuit (I<sup>2</sup>C) pins' bus index and name. See [configuration info](#i2cs). |
-| `digital_interrupts` | array | Optional | Any digital interrupts' GPIO number. See [configuration info](#digital_interrupts). |
-| `pins` | array | Optional | The GPIO number of any GPIO pins you wish to use as input/output with the [board API](/reference/apis/components/board/#api). |
-
-Any pin not specified in either `"pins"` or `"digital_interrupts"` cannot be interacted with through the [board API](/reference/apis/components/board/#api).
-Interaction with digital interrupts is only supported with the [board API](/reference/apis/components/board/#api); these digital interrupts cannot be used as software interrupts in driver implementations.
-
-## `analogs`
-
-The following properties are available for `analogs`:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `name` | string | **Required** | Your name for the analog reader. |
-| `pin`| integer | **Required** | The GPIO number of the ADC's connection pin, wired to the board. |
-
-### `i2cs`
-
-The following properties are available for `i2cs`:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-|`name`| string| **Required** | `name` of the I<sup>2</sup>C bus. |
-|`bus`| string | **Required** | The index of the I<sup>2</sup>C bus. Must be either `i2c0` or `i2c1`. |
-|`data_pin`| integer | Optional | The GPIO number of the data pin. Default: `11`. |
-|`clock_pin`| integer | Optional | The GPIO number of the clock pin. Default: `6`. |
-|`baudrate_hz`| integer | Optional | The baudrate in HZ of this I<sup>2</sup>C bus. <br> Default: `1000000` |
-|`timeout_ns`| integer | Optional | Timeout period for this I<sup>2</sup>C bus in nanoseconds. <br> Default: `0` |
-
-### `digital_interrupts`
-
-The following properties are available for `digital_interrupts`:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-|`pin`| integer | **Required** | The GPIO number of the board's GPIO pin that you wish to configure the digital interrupt for. |
-
-### PWM signals on `esp32` pins
-
-You can set PWM frequencies with Viam through the [`GPIOPin` API](/reference/apis/components/board/#api).
-Refer to the [Espressif documentation for valid frequencies and duty resolutions](https://docs.espressif.com/projects/esp-idf/en/v5.4/esp32/api-reference/peripherals/ledc.html#supported-range-of-frequency-and-duty-resolutions).
-A configured `esp32` board can support a maximum of four different PWM frequencies simultaneously, as the boards only have four available timers.
-
-For example:
-
-| Pin | PWM Frequency (Hz) |
-| --- | ------------------ |
-| 12  | 2000               |
-| 25  | 3000               |
-| 26  | 5000               |
-| 32  | 6000               |
-
-At this point, if you want to add another PWM signal, you must do the following:
-
-1. Set the PWM frequency before the duty cycle.
-2. Set the PWM frequency to one of the above previously set frequencies.
-
-For example, you can set pin 33 to 2000 Hz:
-
-| Pin    | PWM Frequency (Hz) |
-| ------ | ------------------ |
-| 12, 33 | 2000               |
-| 25     | 3000               |
-| 26     | 5000               |
-| 32     | 6000               |
-
-Then, follow these requirements to change the PWM frequencies of a pin:
-
-1. If no other pins have a signal of the same frequency (for example, pins 25, 26, and 32), you can freely change their PWM frequency.
-2. If one or more pins are sharing the old frequency (for example, pins 12 and 33):
-   1. If there are less than 4 active frequencies, you can change the PWM frequency freely because there will be a timer available.
-   2. If there are already 4 active frequencies, changing the PWM frequency of the pin will raise an error because there are no timers available. Free a timer by setting the PWM frequencies of all of the pins to 0.
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/board.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/board/" customTitle="Board API" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/tutorials/get-started/blink-an-led/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/board/fake.md b/docs/operate/reference/components/board/fake.md
deleted file mode 100644
index 35a6fc334b..0000000000
--- a/docs/operate/reference/components/board/fake.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: "Configure a Fake Board"
-linkTitle: "fake"
-weight: 20
-type: "docs"
-description: "Configure a fake board."
-images: ["/icons/components/board.svg"]
-tags: ["board", "components"]
-aliases:
-  - "/components/board/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
-# SMEs: Gautham, Rand
----
-
-The `fake` board returns incrementing values for digital interrupt ticks and analogs.
-
-Configure a `fake` board to test integrating a board into your machine without physical hardware:
-
-{{< tabs name="Configure an fake Board" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `board` type, then select the `fake` model.
-Enter a name or use the suggested name for your board and click **Create**.
-
-![An example configuration for a fake board.](/components/board/fake-ui-config.png)
-
-Edit the attributes as applicable to your board, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-fake-board-name>",
-      "model": "fake",
-      "api": "rdk:component:board",
-      "attributes": {
-        "fail_new": <boolean>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `fake` boards:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `fail_new` | bool | **Required** | If the fake board should raise an error at machine start-up. |
-| `analogs` | object | Optional | Attributes of any pins that can be used as Analog-to-Digital Converter (ADC) inputs. See [configuration info](#analogs). |
-| `digital_interrupts` | object | Optional | Pin and name of any digital interrupts. See [configuration info](#digital_interrupts). |
-
-## Attribute configuration
-
-Configuring these attributes on your board allows you to integrate [analog-to-digital converters](#analogs) and [digital interrupts](#digital_interrupts) into your machine.
-
-### `analogs`
-
-{{< readfile "/static/include/components/board/board-analogs.md" >}}
-
-### `digital_interrupts`
-
-{{< readfile "/static/include/components/board/board-digital-interrupts.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/board.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/board/" customTitle="Board API" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/tutorials/get-started/blink-an-led/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/button/_index.md b/docs/operate/reference/components/button/_index.md
deleted file mode 100644
index 333bbf185c..0000000000
--- a/docs/operate/reference/components/button/_index.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: "Button Component"
-linkTitle: "Button"
-childTitleEndOverwrite: "Button Component"
-weight: 20
-type: "docs"
-description: "A physical button on a machine."
-tags: ["button", "components"]
-icon: true # this should be used when the image is an icon, it will adjust the sizing and object-fit
-images: ["/icons/components/button.svg"]
-no_list: true
-modulescript: true
-date: "2025-02-20"
-# SMEs:
----
-
-The button component provides an API for getting presses of a physical button on a machine.
-
-## Configuration
-
-To use your button component, check whether one of the following models supports it.
-
-For configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:button" type="component" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [button API](/reference/apis/components/button/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/button-table.md" >}}
-
-## Troubleshooting
-
-If your button is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your button model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the button there.
-1. Disconnect and reconnect your button.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/tutorials/services/plan-motion-with-arm-gripper" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/_index.md b/docs/operate/reference/components/camera/_index.md
deleted file mode 100644
index f26f024004..0000000000
--- a/docs/operate/reference/components/camera/_index.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: "Camera Component"
-linkTitle: "Camera"
-childTitleEndOverwrite: "Camera Component"
-weight: 40
-type: "docs"
-description: "A camera captures 2D or 3D images and sends them to the computer controlling the machine."
-no_list: true
-tags: ["camera", "components"]
-icon: true
-images: ["/icons/components/camera.svg"]
-modulescript: true
-aliases:
-  - "/tutorials/configure-a-camera"
-  - "/components/camera/"
-date: "2024-10-21"
-# SMEs: Bijan, vision team
----
-
-The camera component provides an API for getting images or point clouds.
-
-If you have a physical camera or software that generates 2D images or 3D point clouds, use a camera component.
-
-You can use the camera component to configure a webcam, lidar, time-of-flight sensor, or another type of camera.
-You can also use camera models to manipulate the output of other cameras to transform, crop, or otherwise change the output.
-
-{{<youtube embed_url="https://www.youtube-nocookie.com/embed/iKCMo89oyfw">}}
-
-## Configuration
-
-To use a camera with your machine, you need to add it to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your camera.
-
-The following list shows the available camera models.
-The configuration of your camera component depends on your camera model.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:camera" type="camera" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`fake`](fake-micro-server/) | A camera model for testing. |
-| [`esp32-camera`](esp32-camera/) | A camera on an ESP32. |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [camera API](/reference/apis/components/camera/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/camera-table.md" >}}
-
-## Troubleshooting
-
-If your camera is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your camera model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the camera there.
-1. Disconnect and reconnect your camera.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-### Common errors
-
-{{% expand "Failed to find the best driver that fits the constraints" %}}
-
-When working with a [camera](/operate/reference/components/camera/) component, depending on the camera, you may need to explicitly provide some camera-specific configuration parameters.
-
-Check the specifications for your camera, and manually provide configuration parameters such as width and height to the camera component configuration panel.
-On the **CONFIGURE** page, find your camera, then fill in your camera's specific configuration either using the **Show more** button to show the relevant configuration options, or the **JSON** button to enter these attributes manually.
-Provide at least the width and height values to start.
-
-{{% /expand%}}
-
-{{% expand "Resource locking" %}}
-
-If you are using the Camera API in conjunction with tools like OpenCV, you can not grab images using the third party tool from the camera device while in use with the Camera API.
-
-If you are running into this issue, consider the following solutions:
-
-- using the Camera API to get images and then passing them to your third party tool.
-- run a `viam-server` on a more powerful machine and configure it as a {{< glossary_tooltip term_id="remote-part" text="remote part" >}} with a vision service to evaluate images.
-
-{{% /expand%}}
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
-
-You can also use the camera component with the following services:
-
-- [Data management service](/data/capture-sync/capture-and-sync-data/): To capture and sync the camera's data
-- [Vision service](/reference/services/vision/): To use computer vision to interpret the camera stream
-- [SLAM service](/operate/reference/services/slam/): For mapping (with a depth camera)
-
-{{% hiddencontent %}}
-There's no model of transform camera available to mirror the camera image.
-{{% /hiddencontent %}}
diff --git a/docs/operate/reference/components/camera/calibrate.md b/docs/operate/reference/components/camera/calibrate.md
deleted file mode 100644
index 4ae3eb7c6b..0000000000
--- a/docs/operate/reference/components/camera/calibrate.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: "Calibrate a Camera"
-linkTitle: "Calibrate a Camera"
-weight: 80
-type: "docs"
-description: "Calibrate a camera and extract the intrinsic and distortion parameters."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components"]
-aliases:
-  - "/components/camera/calibrate/"
-no_component: true
-date: "2024-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-To calibrate a camera, you can use the classical example of a [chessboard](https://en.wikipedia.org/wiki/Chessboard_detection).
-The chessboard is often used because the geometry makes it a good test case for detection and processing.
-
-## Prerequisites
-
-The calibration code uses the `numpy` and `opencv-python` packages.
-To follow along, install the libraries:
-
-```sh {class="command-line" data-prompt="$"}
-pip3 install numpy
-pip3 install opencv-python
-```
-
-### Instructions
-
-1. Print out the [checkerboard](https://github.com/viam-labs/camera-calibration/blob/main/Checkerboard-A4-25mm-8x6.pdf) and attach it to a flat surface that doesn't distort the checkerboard.
-   Good surfaces are completely flat like a table, an non-textured wall or an acrylic plate.
-   Do not hold the image in the air with your hands or tape it to a textured surface such as a textured wall, cardboard, or folder.
-2. Take images of the checkerboard with your camera from various angles and distances that show the entire image, including the edges.
-   Ensure the image is well and thoroughly lit to avoid distortions affecting the vision algorithms.
-   You can use the **Export screenshot** button on the camera panel of your machine's **CONTROL** tab.
-   Save between 10 - 15 images (see [examples](https://github.com/viam-labs/camera-calibration#example-images)).
-
-   {{< alert title="Important" color="note" >}}
-   In order for the calibration to be compatible with the {{< glossary_tooltip term_id="rdk" text="RDK" >}}, take the images by running the camera using the RDK.
-   {{< /alert >}}
-
-   Example of good images:
-   ![Example of good images](/components/camera/calibrate/example-images.png)
-
-3. Save [`cameraCalib.py`](https://github.com/viam-labs/camera-calibration/blob/main/cameraCalib.py)
-4. Run `python3 cameraCalib.py YOUR_PICTURES_DIRECTORY`.
-
-   Example output:
-
-   ```json {class="line-numbers linkable-line-numbers"}
-   "intrinsic_parameters": {
-       "fy": 940.2928257873841,
-       "height_px": 480,
-       "ppx": 320.6075282958033,
-       "ppy": 239.14408757087756,
-       "width_px": 640,
-       "fx": 939.2693584627577
-   },
-   "distortion_parameters": {
-       "rk2": 0.8002516496932317,
-       "rk3": -5.408034254951954,
-       "tp1": -0.000008996658362365533,
-       "tp2": -0.002828504714921335,
-       "rk1": 0.046535971648456166
-   }
-   ```
-
-5. Copy the output which contains the `intrinsic_parameters` and `distortion_parameters` into the JSON config on your machine's **CONFIGURE** tab.
-
-{{<imgproc src="/components/camera/camera_tutorial_copy_paste.png" resize="800x" declaredimensions=true alt="Config tab with configuration snippet highlighted">}}
-
-The following is a full example config:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "color",
-      "model": "webcam",
-      "api": "rdk:component:camera",
-      "attributes": {
-        "intrinsic_parameters": {
-          "fy": 940.2928257873841,
-          "height_px": 480,
-          "ppx": 320.6075282958033,
-          "ppy": 239.14408757087756,
-          "width_px": 640,
-          "fx": 939.2693584627577
-        },
-        "distortion_parameters": {
-          "rk2": 0.8002516496932317,
-          "rk3": -5.408034254951954,
-          "tp1": -0.000008996658362365533,
-          "tp2": -0.002828504714921335,
-          "rk1": 0.046535971648456166
-        },
-        "stream": "",
-        "debug": false,
-        "format": "",
-        "video_path": "video0",
-        "width_px": 0,
-        "height_px": 0
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/esp32-camera.md b/docs/operate/reference/components/camera/esp32-camera.md
deleted file mode 100644
index 5f90943043..0000000000
--- a/docs/operate/reference/components/camera/esp32-camera.md
+++ /dev/null
@@ -1,205 +0,0 @@
----
-title: "Configure an esp32-camera (Micro-RDK)"
-linkTitle: "esp32-camera (Micro-RDK)"
-weight: 33
-type: "docs"
-description: "Configure a camera connected to an esp32 board, initialized and configured using esp-idf."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components", "Micro-RDK"]
-component_description: "An `OV2640` or `OV3660` camera connected to an esp32 board."
-micrordk_component: true
-toc_hide: true
-date: "2024-08-28"
-aliases:
-  - /components/camera/esp32-camera/
-# updated: ""  # When the content was last entirely checked
-# SMEs: Matt Perez, Micro-RDK team
----
-
-`esp32-camera` is the camera model that supports all cameras that work with Espressif's [esp32-camera drivers](https://github.com/espressif/esp32-camera) including:
-
-- `OV2640`
-
-  - [Datasheet](https://www.uctronics.com/download/OV2640_DS.pdf)
-  - 1600 x 1200, Color, ¼” lens
-  - You can use a cam ribbon adapter to connect to your `esp32` board
-
-- `OV3660`: an [m5 camera timer module](https://docs.m5stack.com/en/unit/timercam_f)
-  - [Datasheet](https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/datasheet/unit/OV3660_CSP3_DS_1.3_sida.pdf)
-  - 2048 x 1536, Color, ⅕” lens
-
-For example, the `OV2640` with a ribbon cable connected to an ESP32:
-
-{{< imgproc src="/components/camera/esp32-camera-2640.png" alt="Fake Camera on the ESP32" resize="300x" class="shadow" >}}
-
-{{< alert title="Software requirements" color="note" >}}
-To use this model, you must follow the [Set up an ESP32 guide](/operate/install/setup-micro/#build-and-flash-custom-firmware), which enables you to install and activate the ESP-IDF.
-When you create a new project with `cargo generate`, select the option to include camera module traits when prompted.
-Finish building and flashing custom firmware, then return to this guide.
-{{< /alert >}}
-
-{{< alert title="Data management not supported" color="caution" >}}
-
-The `esp32-camera` camera model does not currently support the [data management service](/data/capture-sync/capture-and-sync-data/).
-
-{{< /alert >}}
-
-First, connect your camera to your machine's microcontroller and turn the microcontroller on.
-Then, configure your camera:
-
-{{< tabs name="Configure a esp32-camera" >}}
-{{% tab name="JSON Template" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Select **JSON** mode.
-Copy and paste the following JSON into your existing machine configuration into the `"components"` array:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-    "name": "my-esp32camera",
-    "api": "rdk:component:camera",
-    "model": "esp32-camera",
-    "attributes": {
-        "pin_d4": <int>,
-        "jpeg_quality": <int>,
-        "frame_size": <int>,
-        "pin_d5": <int>,
-        "pin_d3": <int>,
-        "pin_d6": <int>,
-        "pin_vsync": <int>,
-        "ledc_timer": <int>,
-        "pin_d7": <int>,
-        "pin_sccb_sda": <int>,
-        "pin_href": <int>,
-        "pin_sccb_scl": <int>,
-        "sccb_i2c_port": <int>,
-        "pin_d1": <int>,
-        "pin_d0": <int>,
-        "pin_xclk": <int>,
-        "pin_reset": <int>,
-        "pin_pclk": <int>,
-        "pin_d2": <int>,
-        "xclk_freq_hz": <int>,
-        "ledc_channel": <int>
-    }
-}
-```
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Example: OV2640" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "my-esp32camera",
-  "api": "rdk:component:camera",
-  "model": "esp32-camera",
-  "attributes": {
-    "pin_pwdn": -1,
-    "pin_reset": -1,
-    "pin_xclk": 21,
-    "pin_sccb_sda": 26,
-    "pin_sccb_scl": 27,
-    "pin_d7": 35,
-    "pin_d6": 34,
-    "pin_d5": 39,
-    "pin_d4": 36,
-    "pin_d3": 19,
-    "pin_d2": 18,
-    "pin_d1": 5,
-    "pin_d0": 4,
-    "pin_vsync": 25,
-    "pin_href": 23,
-    "pin_pclk": 22,
-    "xclk_freq_hz": 20000000,
-    "ledc_timer": 1,
-    "ledc_channel": 1
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example: OV3660" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "my-esp32camera",
-  "api": "rdk:component:camera",
-  "model": "esp32-camera",
-  "attributes": {
-    "pin_d4": 39,
-    "jpeg_quality": 32,
-    "frame_size": 5,
-    "pin_d5": 18,
-    "pin_d3": 5,
-    "pin_d6": 36,
-    "pin_vsync": 22,
-    "ledc_timer": 1,
-    "pin_d7": 19,
-    "pin_sccb_sda": 25,
-    "pin_href": 26,
-    "pin_sccb_scl": 23,
-    "sccb_i2c_port": -1,
-    "pin_d1": 35,
-    "pin_d0": 32,
-    "pin_xclk": 27,
-    "pin_reset": 15,
-    "pin_pclk": 21,
-    "pin_d2": 34,
-    "xclk_freq_hz": 20000000,
-    "ledc_channel": 1
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% alert title="Note" color="note" %}}
-While the following attributes marked as **Optional** do have defaults, it is recommended that you configure them according to your datasheet as your device may not align with the defaults which could cause damage to your board or camera.
-{{% /alert %}}
-
-The following attributes are available for `esp32-camera` cameras:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `pin_pwdn` | int | Optional | GPIO pin for camera power down line. <br> Default: -1 |
-| `pin_reset` | int | Optional | GPIO pin for camera reset line. <br> Default: -1 |
-| `pin_xclk` | int | Optional | GPIO pin for camera XCLK line. <br> Default: 21 |
-| `pin_sccb_sda` | int | Optional | GPIO pin for camera SDA line. <br> Default: 26 |
-| `pin_sccb_scl` | int | Optional | GPIO pin for camera SCL line. <br> Default: 27 |
-| `pin_d7` | int | Optional | GPIO pin for camera D7 line. <br> Default: 35|
-| `pin_d6` | int | Optional | GPIO pin for camera D6 line. <br> Default: 34 |
-| `pin_d5` | int | Optional | GPIO pin for camera D5 line. <br> Default: 39 |
-| `pin_d4` | int | Optional | GPIO pin for camera D4 line. <br> Default: 36 |
-| `pin_d3` | int | Optional | GPIO pin for camera D3 line. <br> Default: 19 |
-| `pin_d2` | int | Optional | GPIO pin for camera D2 line. <br> Default: 18 |
-| `pin_d1` | int | Optional | GPIO pin for camera D1 line. <br> Default: 5 |
-| `pin_d0` | int | Optional | GPIO pin for camera D0 line. <br> Default: 4 |
-| `pin_vsync` | int | Optional | GPIO pin for camera VSYNC line. <br> Default: 25 |
-| `pin_href` | int | Optional | GPIO pin for camera HREF line. <br> Default: 23 |
-| `pin_pclk` | int | Optional | GPIO pin for camera PLCK line. <br> Default: 22 |
-| `xclk_freq_hz` | int | Optional | Frequency of XCLK signal, in Hz. <br> Experimental: Set to 16MHz on ESP32-S2 or ESP32-S3 to enable EDMA mode. <br> Default: 20000000 |
-| `ledc_timer` | int | Optional | LEDC timer to generate XCLK. <br> Default: 1 |
-| `ledc_channel` | int | Optional | LEDC channel to generate XCLK. <br> Default: 1 |
-| `frame_size` | int | Optional | Size of the output image. <br> Default: 1 |
-| `jpeg_quality` | int | Optional | Quality of JPEG output. Lower means higher quality. <br> Range: 0-63 <br> Default: 32 |
-
-## View the camera stream
-
-{{< readfile "/static/include/components/camera-view-camera-stream.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/camera.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/fake-micro-server.md b/docs/operate/reference/components/camera/fake-micro-server.md
deleted file mode 100644
index a59768e31d..0000000000
--- a/docs/operate/reference/components/camera/fake-micro-server.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "Configure a Fake Camera (Micro-RDK)"
-linkTitle: "fake (Micro-RDK)"
-weight: 20
-type: "docs"
-description: Configure a camera to use for testing."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components"]
-aliases:
-  - /components/camera/fake-micro-server/
-component_description: "A camera model for testing."
-micrordk_component: true
-toc_hide: true
-# SMEs: Matt Perez, Micro-RDK team
----
-
-A `fake` camera is a camera model for testing.
-The camera always returns the same image, which is an image of a circle inside a diamond.
-
-{{< alert title="Software requirements" color="note" >}}
-To use this model, you must follow the [Set up an ESP32 guide](/operate/install/setup-micro/#build-and-flash-custom-firmware), which enables you to install and activate the ESP-IDF.
-When you create a new project with `cargo generate`, select the option to include camera module traits when prompted.
-Finish building and flashing custom firmware, then return to this guide.
-{{< /alert >}}
-
-{{< tabs name="Configure a Fake Camera" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `camera` type, then select the `fake` model.
-Enter a name or use the suggested name for your camera and click **Create**.
-
-![Configuration of a fake camera.](/components/camera/configure-fake.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-camera-name>",
-  "model": "fake",
-  "api": "rdk:component:camera",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## View the camera stream
-
-Once your camera is configured, expand the **TEST** section on the configuration pane.
-You will see the live video feed from your camera.
-You can change the refresh frequency as needed to change bandwidth.
-
-{{< imgproc src="/components/camera/fake-micro-server-view.png" alt="Fake Camera Micro Server View" resize="400x" class="shadow"  >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/camera.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/fake.md b/docs/operate/reference/components/camera/fake.md
deleted file mode 100644
index fffd1adad4..0000000000
--- a/docs/operate/reference/components/camera/fake.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: "Configure a Fake Camera"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: Configure a camera to use for testing."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components"]
-aliases:
-  - "/components/camera/fake/"
-component_description: "A camera model for testing."
-toc_hide: true
-# SMEs: Bijan, vision team
----
-
-A `fake` camera is a camera model for testing.
-The camera always returns the same image, which is an image of a gradient.
-This camera also returns a point cloud.
-
-You can optionally specify a height and width.
-
-{{< tabs name="Configure a Fake Camera" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `camera` type, then select the `fake` model.
-Enter a name or use the suggested name for your camera and click **Create**.
-
-![Configuration of a fake camera.](/components/camera/configure-fake.png)
-
-Edit the attributes as applicable to your camera, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-camera-name>",
-  "model": "fake",
-  "api": "rdk:component:camera",
-  "attributes": {
-    "width": <int>,
-    "height": <int>
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `fake` cameras:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `width` | int | Optional | The width of the image in pixels. The maximum width is 10000. <br> Default: `1280` |
-| `height` | int | Optional | The height of the image in pixels. The maximum height is 10000. <br> Default: `720` |
-| `animated` | bool | Optional | If you want the camera stream visible on the **CONTROL** tab to be animated. <br> Default: `False` |
-| `rtp_passthrough` | bool | Optional | If true, `GetImages` will ignore width, height, and animated config params. Default: `False`. |
-| `model` | bool | Optional  | If true, provides `IntrinsicParams` and `DistortionParams` for the camera. Default: `False`. |
-
-## View the camera stream
-
-Once your camera is configured, go to the **CONTROL** tab, and click on the camera's dropdown menu.
-Then toggle the camera or the Point Cloud Data view to ON.
-You will see the live video feed from your camera.
-You can change the refresh frequency as needed to change bandwidth.
-
-{{< imgproc src="/components/camera/fake-view.png" alt="Fake Camera View" resize="600x" class="shadow"  >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/camera.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/ffmpeg.md b/docs/operate/reference/components/camera/ffmpeg.md
deleted file mode 100644
index ab5f4dd893..0000000000
--- a/docs/operate/reference/components/camera/ffmpeg.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: "Configure an ffmpeg Camera"
-linkTitle: "ffmpeg"
-weight: 30
-type: "docs"
-description: "Uses a camera device, a video file, or a stream as a camera."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components"]
-aliases:
-  - "/components/camera/ffmpeg/"
-component_description: "Use a camera, a video file, or a stream as a camera component."
-toc_hide: true
-# SMEs: Sean Yu, audio/video team
----
-
-The `ffmpeg` camera model uses a camera device, a video file, or a stream as a camera.
-
-When used with a streaming camera, the `ffmpeg` camera model supports any streaming camera format that is supported by the [`ffmpeg` program](https://ffmpeg.org/), including MJPEG, H264, and MP4.
-
-{{< alert title="Note" color="note" >}}
-The [`ffmpeg` program](https://ffmpeg.org/) program must be installed separately from `viam-server` on your system for this driver to work.
-{{< /alert >}}
-
-First, connect your camera to your machine's computer and power both on.
-Then, configure your camera:
-
-{{< tabs name="Configure a ffmpeg camera" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `camera` type, then select the `ffmpeg` model.
-Enter a name or use the suggested name for your camera and click **Create**.
-
-![Configuration of a ffmpeg camera.](/components/camera/configure-ffmpeg.png)
-
-Edit the attributes as applicable to your camera, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-camera-name>",
-  "model": "rdk:builtin:ffmpeg",
-  "api": "rdk:component:camera",
-  "attributes": {
-    "intrinsic_parameters": {
-      "width_px": <int>,
-      "height_px": <int>,
-      "fx": <float>,
-      "fy": <float>,
-      "ppx": <float>,
-      "ppy": <float>
-    },
-    "distortion_parameters": {
-      "rk1": <float>,
-      "rk2": <float>,
-      "rk3": <float>,
-      "tp1": <float>,
-      "tp2": <float>
-    },
-    "video_path": "<your-video-path>",
-    "input_kw_args": { ... },
-    "filters": [
-      {
-        "name": <string>,
-        "args": [ "<first>", "<second>", ... ],
-        "kw_args": { ... }
-      }
-    ],
-    "output_kw_args": { ... },
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "stream-camera",
-  "api": "rdk:component:camera",
-  "model": "rdk:builtin:ffmpeg",
-  "attributes": {
-    "video_path": "udp://127.0.0.1:23000",
-    "distortion_parameters": {},
-    "intrinsic_parameters": {
-      "height_px": 2486,
-      "width_px": 1970
-    }
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `ffmpeg` cameras:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `video_path` | string | **Required** | The file path to the camera device, color image file, or streaming camera. If you are using a camera with an RTSP stream, provide the RTSP address to this attribute. |
-| `intrinsic_parameters` | object | Optional | The intrinsic parameters of the camera used to do 2D <-> 3D projections: <ul> <li> <code>width_px</code>: The expected width of the aligned image in pixels. Value must be positive. </li> <li> <code>height_px</code>: The expected height of the aligned image in pixels. Value must be positive. </li> <li> <code>fx</code>: The image center x point. </li> <li> <code>fy</code>: The image center y point. </li> <li> <code>ppx</code>: The image focal x. </li> <li> <code>ppy</code>: The image focal y. </li> </ul> |
-| `distortion_parameters` | object | Optional | Modified Brown-Conrady parameters used to correct for distortions caused by the shape of the camera lens: <ul> <li> <code>rk1</code>: The radial distortion x. </li> <li> <code>rk2</code>: The radial distortion y. </li> <li> <code>rk3</code>: The radial distortion z. </li> <li> <code>tp1</code>: The tangential distortion x. </li> <li> <code>tp2</code>: The tangential distortion y. </li> </ul> |
-| `input_kw_args` | object | Optional | The input keyword arguments. |
-| `filters` | array | Optional | Array of filter objects that specify: <ul> <li> <code>name</code>: The name of the filter. </li> <li> <code>args</code>: The arguments for the filter. </li> <li> <code>kw_args</code>: Any keyword arguments for the filter. </li> </ul> |
-| `output_kw_args` | object | Optional | The output keyword arguments. |
-
-## View the camera stream
-
-{{< readfile "/static/include/components/camera-view-camera-stream.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/camera.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/image-file.md b/docs/operate/reference/components/camera/image-file.md
deleted file mode 100644
index 8c152d1015..0000000000
--- a/docs/operate/reference/components/camera/image-file.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: "Configure an Image File Camera"
-linkTitle: "image_file"
-weight: 31
-type: "docs"
-description: "Configure a camera that gets color or depth images frames from a file path."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components"]
-aliases:
-  - "/components/camera/image-file/"
-component_description: "Gets color and depth image frames from a file path."
-toc_hide: true
-# SMEs: Bijan, vision team
----
-
-An `image_file` camera gets color and depth image frames or point clouds from a file path on your local system.
-
-{{< tabs name="Configure an Image File Camera" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `camera` type, then select the `image_file` model.
-Enter a name or use the suggested name for your camera and click **Create**.
-
-![Configuration of an image file camera.](/components/camera/configure-image-file.png)
-
-Edit the attributes as applicable to your camera, according to the table below.
-Note that you _must_ specify at least one of `color_image_file_path`, `depth_image_file_path`, and `pointcloud_file_path`.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-camera-name>",
-  "model": "image_file",
-  "api": "rdk:component:camera",
-  "attributes": {
-    "intrinsic_parameters": {
-      "width_px": <int>,
-      "height_px": <int>,
-      "fx": <float>,
-      "fy": <float>,
-      "ppx": <float>,
-      "ppy": <float>
-    },
-    "distortion_parameters": {
-      "rk1": <float>,
-      "rk2": <float>,
-      "rk3": <float>,
-      "tp1": <float>,
-      "tp2": <float>
-    },
-    "color_image_file_path": "<your-file-path>",
-    "depth_image_file_path": "<your-file-path>",
-    "pointcloud_file_path": "<your-file-path>",
-    "preloaded_image: "<pizza|dog|crowd>"
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `image_file` cameras:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `intrinsic_parameters` | object | Optional | The intrinsic parameters of the camera used to do 2D <-> 3D projections: <ul> <li> <code>width_px</code>: The expected width of the aligned image in pixels. Value must be >= 0. </li> <li> <code>height_px</code>: The expected height of the aligned image in pixels. Value must be >= 0. </li> <li> <code>fx</code>: The image center x point. </li> <li> <code>fy</code>: The image center y point. </li> <li> <code>ppx</code>: The image focal x. </li> <li> <code>ppy</code>: The image focal y. </li> </ul> |
-| `distortion_parameters` | object | Optional | Modified Brown-Conrady parameters used to correct for distortions caused by the shape of the camera lens: <ul> <li> <code>rk1</code>: The radial distortion x. </li> <li> <code>rk2</code>: The radial distortion y. </li> <li> <code>rk3</code>: The radial distortion z. </li> <li> <code>tp1</code>: The tangential distortion x. </li> <li> <code>tp2</code>: The tangential distortion y. </li> </ul> |
-| `color_image_file_path` | string | Optional | The file path to the color image on your local system. |
-| `depth_image_file_path` | string | Optional | The file path to the depth image on your local system. |
-| `pointcloud_file_path` | string | Optional | The file path to the point cloud file on your local system. |
-| `preloaded_image` | string | Optional | Select a pre-loaded image for the camera to display. Options: `"pizza"`, `"dog"`, `"crowd"`. |
-
-You must specify at least one of `color_image_file_path`, `depth_image_file_path`, and `pointcloud_file_path`.
-
-If you provide configuration for the `depth_image_file_path` and `intrinsic_parameters` of the camera, then your machine will also retrieve point cloud data from the `depth_image_file_path`.
-If you then also configure a `pointcloud_file_path` on your camera, Viam will try to pull the data from the `pointcloud_file_path` first.
-
-## View the camera stream
-
-{{< readfile "/static/include/components/camera-view-camera-stream.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/camera.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/transform.md b/docs/operate/reference/components/camera/transform.md
deleted file mode 100644
index 5935fc9c51..0000000000
--- a/docs/operate/reference/components/camera/transform.md
+++ /dev/null
@@ -1,333 +0,0 @@
----
-title: "Transform Camera"
-linkTitle: "transform"
-weight: 60
-type: "docs"
-description: "Use the transform camera model to apply transformation to a camera stream. For example, crop, resize, or add overlays with info about the camera stream."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components"]
-aliases:
-  - "/components/camera/transform/"
-component_description: "Use pipelines for applying transformations to an input image source."
-toc_hide: true
-# SMEs: Rand, AV team
----
-
-Use the `transform` model to apply transformations to input source images.
-The transformations are applied in the order they are written in the `pipeline`.
-
-{{< tabs name="Example transform view" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Configuration block**.
-Select the `camera` type, then select the `transform` model.
-Enter a name or use the suggested name for your camera and click **Create**.
-
-Copy and paste the following attribute template into the attributes field.
-Then remove and fill in the attributes as applicable to your camera, according to the table below.
-
-{{< tabs >}}
-{{% tab name="Attributes template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source" : "<your-camera-name>",
-  "pipeline": [
-    { "type": "<transformation-type>", "attributes": { ... } },
-  ],
-  "intrinsic_parameters": {
-    "width_px": <int>,
-    "height_px": <int>,
-    "fx": <float>,
-    "fy": <float>,
-    "ppx": <float>,
-    "ppy": <float>
-  },
-  "distortion_parameters": {
-  "rk1": <float>,
-    "rk2": <float>,
-    "rk3": <float>,
-    "tp1": <float>,
-    "tp2": <float>
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="Attributes example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "my-webcam",
-  "pipeline": [
-    { "type": "rotate", "attributes": {} },
-    { "type": "resize", "attributes": { "width_px": 200, "height_px": 100 } }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-camera-name>",
-  "model": "transform",
-  "api": "rdk:component:camera",
-  "attributes" : {
-    "source" : "<your-source-camera-name>",
-    "pipeline": [
-      { "type": "<transformation-type>", "attributes": { ... } },
-    ],
-    "intrinsic_parameters": {
-      "width_px": <int>,
-      "height_px": <int>,
-      "fx": <float>,
-      "fy": <float>,
-      "ppx": <float>,
-      "ppy": <float>
-    },
-    "distortion_parameters": {
-      "rk1": <float>,
-      "rk2": <float>,
-      "rk3": <float>,
-      "tp1": <float>,
-      "tp2": <float>
-    }
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `transform` views:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `source` | string | **Required** | `name` of the camera to transform. |
-| `pipeline` | array | **Required** | Specify an array of transformation objects. |
-| `intrinsic_parameters` | object | Optional | The intrinsic parameters of the camera used to do 2D <-> 3D projections: <ul> <li> <code>width_px</code>: The expected width of the aligned image in pixels. Value must be >= 0.</li> <li> <code>height_px</code>: The expected height of the aligned image in pixels. Value must be >= 0.</li> <li> <code>fx</code>: The image center x point. </li> <li> <code>fy</code>: The image center y point. </li> <li> <code>ppx</code>: The image focal x. </li> <li> <code>ppy</code>: The image focal y. </li> </ul> |
-| `distortion_parameters` | object | Optional | Modified Brown-Conrady parameters used to correct for distortions caused by the shape of the camera lens: <ul> <li> <code>rk1</code>: The radial distortion x. </li> <li> <code>rk2</code>: The radial distortion y. </li> <li> <code>rk3</code>: The radial distortion z. </li> <li> <code>tp1</code>: The tangential distortion x. </li> <li> <code>tp2</code>: The tangential distortion y. </li> </ul> |
-
-The following are the transformation objects available for the `pipeline`:
-
-## Classifications
-
-Classifications overlay text from the `GetClassifications` method of the [vision service](/reference/services/vision/) onto the image.
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "<your-source-camera-name>",
-  "pipeline": [
-    {
-      "type": "classifications",
-      "attributes": {
-        "classifier_name": "<name>",
-        "confidence_threshold": <float>,
-        "max_classifications": <int>,
-        "valid_labels": [ "<label>" ]
-      }
-    }
-  ]
-}
-```
-
-**Attributes:**
-
-- `classifier_name`: The name of the classifier in the [vision service](/reference/services/vision/).
-- `confidence_threshold`: The threshold above which to display classifications.
-- `max_classifications`: _Optional_. The maximum number of classifications to display on the camera stream at any given time. Default: `1`.
-- `valid_labels`: _Optional_. An array of labels that you to see detections for on the camera stream. If not specified, all labels from the classifier are used.
-
-### Crop
-
-The Crop transform trims an image to a rectangular area specified by two points: the top left (`(x_min, y_min)`) and the bottom right (`(x_max, y_max)`).
-You can provide these points as integer pixel values or as decimal proportions of the image's width and height.
-The origin (`(0, 0)`) occupies the top left pixel of the image; X values increase as you move right, Y values increase as you move down.
-
-{{< tabs >}}
-{{% tab name="Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "<your-source-camera-name>",
-  "pipeline": [
-    {
-      "type": "crop",
-      "attributes": {
-        "x_min_px": <int|float>,
-        "y_min_px": <int|float>,
-        "x_max_px": <int|float>,
-        "y_max_px": <int|float>,
-        "overlay_crop_box": <bool>
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Pixel Coordinate Example" %}}
-
-To crop a 100 x 200 image to the rectangular region between pixel coordinates `(30, 40)` and `(60, 80)`, pass those coordinates in the following configuration:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "<your-source-camera-name>",
-  "pipeline": [
-    {
-      "type": "crop",
-      "attributes": {
-        "x_min_px": 30,
-        "y_min_px": 40,
-        "x_max_px": 60,
-        "y_max_px": 80,
-        "overlay_crop_box": false
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Proportional Coordinate Example" %}}
-
-To crop any image to a rectangular region that occupies the central 50% of the image, use proportional coordinates `(0.25, 0.25)` and `(0.75, 0.75)`:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "<your-source-camera-name>",
-  "pipeline": [
-    {
-      "type": "crop",
-      "attributes": {
-        "x_min_px": 0.25,
-        "y_min_px": 0.25,
-        "x_max_px": 0.75,
-        "y_max_px": 0.75,
-        "overlay_crop_box": false
-      }
-    }
-  ]
-}
-```
-
-{{< alert title="Tip" color="tip" >}}
-
-To convert pixel coordinates to proportional, divide **X by image width** and **Y by image height**.
-
-For example, for pixel coordinates `(25, 50)` and `(75, 150)` in a 100 × 200 image:
-
-- `(25, 50)` → `(25 / 100, 50 / 200)` → `(0.25, 0.25)`
-- `(75, 150)` → `(75 / 100, 150 / 200)` → `(0.75, 0.75)`
-
-Use the formula `(X / <image width>, Y / <image height>)`.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-**Attributes:**
-
-- `x_min_px`: The X pixel or proportional value of the top left corner of the crop area.
-- `y_min_px`: The Y pixel or proportional value of the top left corner of the crop area.
-- `x_max_px`: The X pixel or proportional value of the bottom right point of the crop area.
-- `y_max_px`: The Y pixel or proportional value of the bottom right point of the crop area.
-- `overlay_crop_box`: When `true`, instead of cropping, overlays the cropping box on the original image to visualize where the crop would apply.
-
-### Detections
-
-The Detections transform takes the input image and overlays the detections from a given detector configured within the [vision service](/reference/services/vision/).
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "<your-source-camera-name>",
-  "pipeline": [
-    {
-      "type": "detections",
-      "attributes": {
-        "detector_name": string,
-        "confidence_threshold": <float>,
-        "valid_labels": ["<label>"]
-      }
-    }
-  ]
-}
-```
-
-**Attributes:**
-
-- `detector_name`: The name of the detector configured in the [vision service](/reference/services/vision/).
-- `confidence_threshold`: Specify to only display detections above the specified threshold (decimal between 0 and 1).
-- `valid_labels`: _Optional_. An array of labels that you to see detections for on the camera stream. If not specified, all labels from the classifier are used.
-
-### Resize
-
-The Resize transform resizes the image to the specified height and width.
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "<your-source-camera-name>",
-  "pipeline": [
-    {
-      "type": "resize",
-      "attributes": {
-        "width_px": <int>,
-        "height_px": <int>
-      }
-    }
-  ]
-}
-```
-
-**Attributes:**
-
-- `width_px`: Specify the expected width for the aligned image. Value must be >= 0.
-- `height_px`: Specify the expected width for the aligned image. Value must be >= 0.
-
-### Rotate
-
-The Rotate transformation rotates the image by the angle specified in `angle_deg`. Default: 180 degrees.
-This feature is useful for when the camera is installed upside down or sideways on your machine.
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "source": "<your-source-camera-name>",
-  "pipeline": [
-    {
-      "type": "rotate",
-      "attributes": {
-        "angle_degs": <float>
-      }
-    }
-  ]
-}
-```
-
-**Attributes:**
-
-- `angle_deg`: Rotate the image by a specific angle in degrees.
-
-## View the camera stream
-
-{{< readfile "/static/include/components/camera-view-camera-stream.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/camera.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/camera/webcam.md b/docs/operate/reference/components/camera/webcam.md
deleted file mode 100644
index 3f6ee8bc98..0000000000
--- a/docs/operate/reference/components/camera/webcam.md
+++ /dev/null
@@ -1,323 +0,0 @@
----
-title: "Configure a Webcam"
-linkTitle: "webcam"
-weight: 33
-type: "docs"
-description: "Configure a standard camera that streams camera data."
-images: ["/icons/components/camera.svg"]
-tags: ["camera", "components"]
-aliases:
-  - "/components/camera/webcam/"
-component_description: "A standard USB camera or other webcam that streams camera data."
-usage: 999999
-toc_hide: true
-# SMEs: Bijan, vision team
----
-
-`webcam` is the general camera model.
-If the camera drivers are among those in [this mediadevices repository](https://github.com/pion/mediadevices), the camera will work with the webcam model.
-
-First, connect your camera to your machine's computer (unless it is built-in like a webcam on a laptop) and power both on.
-Then, configure your camera:
-
-{{< tabs name="Configure a Webcam" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `camera` type, then select the `webcam` model.
-Enter a name or use the suggested name for your camera and click **Create**.
-
-{{< imgproc src="/components/camera/configure-webcam.png" alt="Configuration of a webcam camera." resize="1200x" style="width=600x" class="shadow"  >}}
-
-Edit and fill in the attributes as applicable.
-Leave the **video_path** blank and the camera will use the default video path for your machine.
-If this doesn't work when you test your camera later, you can try [configuring a video path](#using-video_path).
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-camera-name>",
-  "model": "webcam",
-  "api": "rdk:component:camera",
-  "attributes": {
-    "intrinsic_parameters": {
-      "width_px": <int>,
-      "height_px": <int>,
-      "fx": <float>,
-      "fy": <float>,
-      "ppx": <float>,
-      "ppy": <float>
-    },
-    "distortion_parameters": {
-      "rk1": <float>,
-      "rk2": <float>,
-      "rk3": <float>,
-      "tp1": <float>,
-      "tp2": <float>
-    },
-    "format": <string>,
-    "video_path": "<your-video-path>",
-    "width_px": <int>,
-    "height_px": <int>,
-    "frame_rate": <float>
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "my_cam",
-  "model": "webcam",
-  "api": "rdk:component:camera",
-  "attributes": {
-    "video_path": "video0"
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `webcam` cameras:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `video_path` | string | Optional | The ID of or the path to the webcam. If you don't provide a `video_path`, it defaults to the first valid video path it finds. Using the ID of a webcam is more consistent than the path. See [Using `video_path`](#using-video_path). |
-| `format` | string | Optional | The camera image format, used with `video_path` to find the camera. See [Using `format`](#using-format). |
-| `width_px` | int | Optional | The camera image width in pixels, used with `video_path` to find a camera with this resolution. Negative values are silently ignored and result in the default being used. <br> Default: Closest possible value to `480` |
-| `height_px` | int | Optional | The camera image height in pixels, used with `video_path` to find a camera with this resolution. Negative values are silently ignored and result in the default being used. <br> Default: Closest possible value to `640` |
-| `frame_rate` | float | Optional | The camera capture frequency as frames per second, used with `video_path` to find a camera with this throughput. <br> Default: Closest possible value to `30.0` |
-| `intrinsic_parameters` | object | Optional | The intrinsic parameters of the camera used to do 2D <-> 3D projections: <ul> <li> `width_px`: The expected width of the aligned image in pixels. </li> <li> `height_px`: The expected height of the aligned image in pixels. </li> <li> `fx`: The image center x point. </li> <li> `fy`: The image center y point. </li> <li> `ppx`: The image focal x. </li> <li> `ppy`: The image focal y. </li> </ul> |
-| `distortion_parameters` | object | Optional | Modified Brown-Conrady parameters used to correct for distortions caused by the shape of the camera lens: <ul> <li> `rk1`: The radial distortion x. </li> <li> `rk2`: The radial distortion y. </li> <li> `rk3`: The radial distortion z. </li> <li> `tp1`: The tangential distortion x. </li> <li> `tp2`: The tangential distortion y. </li> </ul> |
-
-## Using `video_path`
-
-### Find a video path using a discovery service
-
-The [`viam:find-webcams:webcam-discovery`](https://app.viam.com/module/viam/find-webcams) service helps you identify path options.
-To add and use the service:
-
-1. Navigate to the **CONFIGURE** tab of your machine's page.
-1. Click the **+** icon next to your machine part in the left-hand menu and select **Service**.
-1. Search for `find-webcams` and select the `discovery / find-webcams:webcam-discovery` service.
-1. Click **Add module**.
-1. Enter a name or use the suggested name for your camera and click **Create**.
-1. Save your configuration, and wait a moment for the service to start.
-1. Click **Test** to see the available `video_path`s.
-
-   {{<imgproc src="/components/camera/webcam-discovery-test.png" alt="The test panel for the find-webcams service." resize="1100x" style="max-width:600px" class="shadow imgzoom" >}}
-
-1. Click the **Copy attributes** button for the camera you want to use.
-1. Click the **JSON** button in the upper right corner of the camera component configuration.
-
-1. Paste the copied attributes.
-1. Click **Save**.
-1. You can now delete the discovery service and the module that provides it from your machine.
-
-### Find a video path using the command line
-
-To list available `video_path`s use the following command:
-
-{{< tabs name="Find video devices" >}}
-{{% tab name="Linux" %}}
-
-```sh {class="command-line" data-prompt="$"}
-ls /dev/v4l/by-id/
-```
-
-To find the `path`s of all connected video devices, run the following command:
-
-```sh {class="command-line" data-prompt="$"}
-v4l2-ctl --list-devices
-```
-
-The `id` listed by `ls /dev/v4l/by-id/` is a more consistent way to refer to the webcam.
-
-{{% /tab %}}
-{{% tab name="Mac" %}}
-
-```sh {class="command-line" data-prompt="$"}
-system_profiler SPCameraDataType
-```
-
-The Unique ID displayed for each camera is the `video_path`.
-
-If you are using macOS version 15.x.x Sequoia or later, you need to give `viam-server` permissions to access webcams.
-When you run `viam-server` for the first time, a pop-up message will ask for camera access.
-Click **Allow**.
-To confirm settings, you can go to **System Settings** > **Privacy & Security** > **Camera** and check that the toggle next to `viam-server` is set to enable access.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Using `format`
-
-Viam supports the following pixel formats:
-
-- I420
-- I444
-- MJPEG / MJPG
-- NV12
-- NV21
-- RGBA
-- UYVY / Y422
-- YUY2 / YUYV / V422
-- Z16
-
-If your machine is connected to Viam, the available pixel formats supported by your camera automatically appear in the **Format** dropdown menu, which is visible when you click the **Show more** button.
-
-On Linux, you can also manually determine which pixel formats your camera supports by running the following command on the machine your camera is connected to.
-Replace `/dev/video0` with the video path you [determined for your video device above](#using-video_path), if different:
-
-```sh {class="command-line" data-prompt="$"}
-v4l2-ctl --list-formats-ext --device /dev/video0
-```
-
-## View the camera stream
-
-{{< readfile "/static/include/components/camera-view-camera-stream.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/camera.md" >}}
-
-{{% expand "Cannot open webcam or found no webcams" %}}
-When working with a [camera](/operate/reference/components/camera/) component on the Linux platform, your Linux OS must be able to access the camera properly, and the camera must be configured to use a pixel format that Viam supports.
-
-On your Linux system, verify each of the following:
-
-- Ensure that your Linux OS is able to access your camera:
-
-  1.  Run the following command to list compatible camera devices on your system:
-
-      ```sh {class="command-line" data-prompt="$"}
-      v4l2-ctl --list-devices
-      ```
-
-      In the list of camera devices returned, find the entry for your camera.
-      For example, the webcam on a rover may appear as follows:
-
-      ```sh {class="command-line" data-prompt="$"}
-      GENERAL WEBCAM: GENERAL WEBCAM (usb-0000:01:00.0-1.4):
-              /dev/video0
-              /dev/video1
-              /dev/media4
-      ```
-
-      The video path for your camera device is the first path listed under that camera, in this case `/dev/video0`.
-
-  1.  Then, [stop `viam-server`](/operate/reference/viam-server/manage-viam-server/#run-viam-server), and verify that your Linux OS is able to access that video device properly:
-
-      ```sh {class="command-line" data-prompt="$"}
-      v4l2-ctl --stream-count 1 --device /dev/video0
-      ```
-
-      Replace `/dev/video0` in the above command with the video path you determined for your video device above, if different.
-
-      The command returns successfully (with no output) if Linux is able to successfully communicate with the camera, or errors with `Cannot open device` if there was a problem communicating.
-      If this command errors, you should consult the documentation for your camera and Linux distribution to troubleshoot.
-      If you receive the error `Device or resource busy` instead, be sure you have [stopped `viam-server`](/operate/reference/viam-server/manage-viam-server/#run-viam-server) first, then re-run the command above.
-
-- Ensure that your camera uses a supported pixel format:
-
-  1.  First, determine your video path, like `/dev/video0`, following the instructions above.
-  1.  Then, run the following command:
-
-      ```sh {class="command-line" data-prompt="$"}
-      v4l2-ctl --list-formats-ext --device /dev/video0
-      ```
-
-      Replace `/dev/video0` in the above command with the video path you determined for your video device above, if different.
-
-      The command will return a list of pixel formats your camera supports, such as `MJPG` (also notated as `MJPEG`) or `YUYV` (also notated as `YUY2`).
-      In order to use a camera device with Viam, it must support at least one of the [pixel formats supported by Viam](/operate/reference/components/camera/webcam/#using-format).
-      If your camera does not support any of these formats, it cannot be used with Viam.
-
-If you are still having issues with your camera component on the Linux platform, and would like to [file an issue](https://github.com/viamrobotics/rdk), include your machine's camera debug file contained in the <file>/root/.viam/debug/components/camera</file> directory.
-If you are running `viam-server` as a different user, find the <file>.viam/debug/components/camera</file> directory in that user's home directory instead.
-This file contains basic diagnostic and configuration information about your camera that helps to quickly troubleshoot issues.
-{{% /expand%}}
-
-{{% expand "No visible live video feed" %}}
-
-Restart `viam-server`:
-
-1. Navigate to your machine's page.
-1. Select the part status dropdown to the right of your machine's name on the top of the page.
-   {{<imgproc src="configure/machine-part-info.png" resize="500x" declaredimensions=true alt="machine cloud credentials button on the machine part info dropdown" class="shadow" >}}
-1. If you installed `viam-server` with `viam-agent` you will see a **Restart** button. Click it.
-   Both `viam-server` and `viam-agent` will restart.
-
-   If you do not see the **Restart** button, click the **...** menu on the right side of the machine part's card, and select **Restart part**.
-   If restarting the machine part does not resolve the issue, ssh into the machine and [stop and restart viam-server manually](/operate/reference/viam-server/manage-viam-server/#run-viam-server).
-
-If this doesn't work, you can reboot your machine by running the following command on the machine:
-
-```sh {class="command-line" data-prompt="$"}
-sudo reboot
-```
-
-{{% /expand%}}
-
-{{% expand "Images are dim on start up" %}}
-If you are capturing camera data, it can happen that the camera captures and syncs discolored or dark images upon start up.
-{{% /expand%}}
-
-{{% expand "CSI Camera not working on a Raspberry Pi" %}}
-
-If you are using a CSI camera v1.3 or v2.0, or v3.0 with a Raspberry Pi, use the `viam:camera:csi-pi` model provided by the [Viam CSI camera module](https://github.com/viamrobotics/csi-camera/) instead.
-For CSI cameras used with Jetsons, use the `viam:camera:csi` model provided by the same module.
-
-For Raspberry Pi AI cameras like the IMX500 AI camera, use a module such as [this `viam-pi-ai-camera` vision service](https://github.com/HipsterBrown/viam-pi-ai-camera).
-For more information about the vision service, see [run inference](https://docs.viam.com/vision/detect/).
-{{% /expand%}}
-
-{{% expand "High CPU usage" %}}
-Camera streams use a significant amount of CPU resources.
-The more CPU resources a device has, the more camera streams you can run simultaneously.
-If your device doesn't have enough CPU resources to support your use case, try lowering the image resolution to decrease the CPU load of the camera streams.
-{{% /expand%}}
-
-{{% expand "macOS camera permissions issues" %}}
-On macOS, if you're having trouble accessing your webcam, you may need to grant camera permissions for the application that you use to run `viam-server`.
-
-**Resetting camera permissions:**
-
-If `viam-server` is not prompting for camera permissions or you need to re-grant permissions, you can reset the camera permissions for all applications using the following command:
-
-```sh {class="command-line" data-prompt="$"}
-tccutil reset Camera
-```
-
-If you know the macOS bundle ID of the application that you use to run `viam-server`, you can pass the bundle ID to limit the camera permissions reset to only that application.
-For instance, you can reset camera permissions for the built-in Terminal app with `tccutil reset Camera com.apple.Terminal`.
-If the command was successful, you should see output similar to the following:
-
-```sh {class="command-line" data-prompt="$"}
-Successfully reset Camera approval status for com.apple.Terminal
-```
-
-After running this command, restart `viam-server` and it should prompt for camera permissions again.
-
-**Checking camera permissions:**
-
-To verify camera permissions, go to **System Settings** > **Privacy & Security** > **Camera**.
-Find the application `viam-server` is running in (such as Terminal or VS Code).
-Ensure that your terminal application has camera access enabled.
-{{% /expand%}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/camera/" customTitle="Camera API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/component/_index.md b/docs/operate/reference/components/component/_index.md
deleted file mode 100644
index feedf5ef60..0000000000
--- a/docs/operate/reference/components/component/_index.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: "Template Component"
-linkTitle: "Template"
-childTitleEndOverwrite: "Template Component"
-weight: 10
-type: "docs"
-description: "A NAME is a ... description of what the component is."
-tags: ["camera", "components"]
-icon: true # this should be used when the image is an icon, it will adjust the sizing and object-fit
-images: ["/icons/components.png"]
-draft: true
-no_list: true
-modulescript: true
-# SMEs:
----
-
-{{<imgproc src="/icons/components.png" resize="400x" declaredimensions=true alt="ALT" class="alignright">}}
-
-Brief description of the component and what you can do with it.
-
-Use cases (optional):
-
-- A brief description of one sample use case.
-- ...
-
-Most machines with a COMPONENT need at least the following hardware (optional):
-
-- Board
-- ...
-
-## Configuration
-
-To use your <COMPONENT> component, check whether one of the following models supports it.
-
-For configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:component" type="component" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Related services
-
-Add services commonly used with the component.
-
-{{< cards >}}
-{{< relatedcard link="/services/data/" >}}
-{{< relatedcard link="/operate/reference/services/frame-system/" >}}
-{{< /cards >}}
-
-## API
-
-The [COMPONENT API](/reference/apis/components/encoder/) supports the following methods:
-
-_Writing Instructions: Use the method names in the [protobuf](https://github.com/viamrobotics/api/blob/main/component/board/v1/board_grpc.pb.go), not the Python or Go-specific method names._
-_Use an included snippet so you can add it to <file>/program/apis/</file>._
-
-{{< readfile "/static/include/components/apis/component.md" >}}
-
-## Troubleshooting
-
-If your COMPONENT is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your COMPONENT model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the COMPONENT there.
-1. Disconnect and reconnect your COMPONENT.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-To get started using your COMPONENT, see the [COMPONENT API](/reference/apis/components/camera/) or check out one of these guides:
-
-<!-- ADD CARDS -->
diff --git a/docs/operate/reference/components/component/board1.md b/docs/operate/reference/components/component/board1.md
deleted file mode 100644
index 3b50eab4e1..0000000000
--- a/docs/operate/reference/components/component/board1.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: "Configure a <board-model> Board"
-linkTitle: "<board-model>"
-weight: 20
-type: "docs"
-description: "Configure a <board-model> board."
-images: ["/icons/components/board.svg"]
-tags: ["board", "components"]
-aliases:
-  - "/components/board/<board-model>/"
-draft: true
-# SMEs:
----
-
-{{% alert title="REQUIREMENTS" color="note" %}}
-
-Follow the [setup guide](/operate/reference/prepare/board1-setup) to prepare your <model-name> to run `viam-server` before you configure your <model-name> board.
-
-{{% /alert %}}
-
-Configure a `<board-model>` board to integrate an [<board-series-model>](http://www.example.com), [<board-series-model-1>](http://example.com), or [<board-series-model-2>](http://example.com) board into your machine.
-
-To test your board as you configure it, power it on.
-If you plan to connect hardware to the board's pins, connect the hardware while it's powered off.
-Then, configure the board:
-
-{{< tabs name="Configure a <board-model> Board" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `board` type, then select the `<board-model>` model.
-Enter a name or use the suggested name for your board and click **Create**.
-
-![An example configuration for a <board-model> board.](/components/board/pi-ui-config.png)
-
-Click the **JSON** button in the top right of the component panel to edit your board's attributes with JSON, according to the following table.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-````json {class="line-numbers linkable-line-numbers"}
-{
-    "analogs": [
-            {
-            "name": "<your-analog-reader-name>",
-            "pin": "<pin-number-on-adc>",
-            "spi_bus": "<your-spi-bus-index>",
-            "chip_select": "<chip-select-index>",
-            "average_over_ms": <int>,
-            "samples_per_sec": <int>
-          }
-        ],
-    "digital_interrupts": [
-          {
-            "name": "<your-digital-interrupt-name>",
-            "pin": "<pin-number>"
-          }
-        ]
-}
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
- "digital_interrupts": [
-          {
-            "name": "your-digital-interrupt-name",
-            "pin": "18"
-          }
-        ]
-}
-````
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `<board-model>` boards:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `digital_interrupts` | object | Optional | Any digital interrupts's {{< glossary_tooltip term_id="pin-number" text="pin number" >}} and name. See [configuration info](#digital_interrupts).|
-| `analogs` | object | Optional | Attributes of any pins that can be used as Analog-to-Digital Converter (ADC) inputs. See [configuration info](#analogs).|
-
-## Attribute configuration
-
-Configure these attributes on your board to integrate [analog-to-digital converters](#analogs) and [digital interrupts](#digital_interrupts) into your machine.
-
-### `analogs`
-
-{{< readfile "/static/include/components/board/board-analogs.md" >}}
-
-### `digital_interrupts`
-
-{{< readfile "/static/include/components/board/board-digital-interrupts.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/board.md" >}}
-
-## Next steps
-
-Text & links
diff --git a/docs/operate/reference/components/component/model1.md b/docs/operate/reference/components/component/model1.md
deleted file mode 100644
index a6670697b9..0000000000
--- a/docs/operate/reference/components/component/model1.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: "Configure a Model1"
-linkTitle: "Model1"
-weight: 12
-type: "docs"
-description: "Configure a model1 arm."
-images: ["/icons/components.png"]
-tags: ["name", "components"]
-draft: true
-# SMEs:
----
-
-The `model1` arm model supports the XYZ unit made by Some Company(INSERT LINK AS APPLICABLE).
-Optional additional description/information.
-
-To be able to test your component as you configure it, first physically assemble the component and connect it to your machine's computer. Power both on.
-Then, configure the component:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `arm` type, then select the `model1` model.
-Enter a name or use the suggested name for your arm and click **Create**.
-
-{{< imgproc src="/components/component/model1-builder.png" alt="Creation of a `model1` arm"  >}}
-
-Edit and fill in the attributes as applicable.
-
-<!-- If the model does not have a fancy config UI available, such that the user needs to write JSON attributes, refer to one of the other component models as an example. You should include easily copy-pastable attribute templates on the config tab. For example, replace "Edit and fill in the attributes as applicable." with the following:
-
-Copy and paste the following attribute template into your COMPONENT's attributes field.
-Then remove and fill in the attributes as applicable to your COMPONENT, according to the table below.
-
-{{< tabs >}}
-{{% tab name="Attributes template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "stream": "<color|depth>",
-  "url": "<URL>",
-  "intrinsic_parameters": {
-    "width_px": <int>,
-    "height_px": <int>,
-    "fx": <float>,
-    "fy": <float>,
-    "ppx": <float>,
-    "ppy": <float>
-  },
-  "distortion_parameters": {
-    "rk1": <float>,
-    "rk2": <float>,
-    "rk3": <float>,
-    "tp1": <float>,
-    "tp2": <float>
-  },
-  "debug": <boolean>
-}
-```
-
-{{% /tab %}}
-{{% tab name="Attributes example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "stream": "color",
-  "url": "http://urltogetstreamingimagedatafrom"
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
--->
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": <arm_name>,
-      "model": "model1",
-      "api": "rdk:component:arm",
-      "attributes": {
-        "board": <string>,
-        "i2c_bus": <string>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "myArm",
-      "model": "model1",
-      "api": "rdk:component:arm",
-      "attributes": {
-        "board": "local",
-        "i2c_bus": "1"
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Annotated JSON" %}}
-
-**Very optional**; probably don't bother making one if you don't already have one handy.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `model1` arms:
-
-<!-- prettier-ignore -->
-| Name         | Required? | Type   | Default Value | Description |
-| ------------ | --------- | ------ | ------------- | ----------- |
-| `board`      | **Required** | string | -             | The name of the board to which the device is wired.                                                                                                                                              |
-| `i2c_bus`    | **Required** | string | -             | The name of the I<sup>2</sup>C bus through which the device communicates with the SBC. Note that this must match the name you gave the I<sup>2</sup>C bus you configured in the board component. |
-| `attributes` | Optional     | int    | 300           | Insert useful description here.                                                                                                                                                                  |
-
-## Test the component
-
-After you configure your component, navigate to the [**CONTROL** tab](/manage/troubleshoot/teleoperate/default-interface/) and select the **Component** dropdown panel.
-
-Then _explain how to interact with the panel_.
-
-{{<imgproc src="/components/sensor/sensor-control-tab.png" resize="800x" declaredimensions=true alt="Image or GIF of the control tab">}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/component.md" >}}
-
-## Next steps
-
-Text & Links
diff --git a/docs/operate/reference/components/encoder/_index.md b/docs/operate/reference/components/encoder/_index.md
deleted file mode 100644
index 325c0f572a..0000000000
--- a/docs/operate/reference/components/encoder/_index.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: "Encoder Component"
-linkTitle: "Encoder"
-childTitleEndOverwrite: "Encoder Component"
-weight: 50
-type: "docs"
-description: "A special type of sensor that measures rotation of a motor or joint."
-tags: ["encoder", "components"]
-icon: true
-images: ["/icons/components/encoder.svg"]
-no_list: true
-modulescript: true
-aliases:
-  - "/components/encoder/"
-  - /micro-rdk/encoder/
-  - /build/micro-rdk/encoder/
-hide_children: true
-date: "2024-10-21"
-# SME: Rand
----
-
-The encoder component provides an API for getting the position of a motor or a joint in ticks or degrees.
-
-If you have hardware or software that provides the position of a motor or joint, use an encoder component.
-
-Encoder components are often used in conjunction with a motor, and are sometimes even built directly into motors.
-Encoders can also be mounted on a passive joint or other rotating object to keep track of the joint angle.
-
-The encoder component supports:
-
-- [Incremental encoders](https://en.wikipedia.org/wiki/Incremental_encoder#Quadrature_outputs), which can measure the speed and direction of rotation in relation to a given reference point like a starting point.
-  These encoders output two phases.
-  Based on the sequence and timing of these phases, it is determined how far something has turned and in which direction.
-  Each phase output goes to a different pin on the board.
-- Single phase or single pin "pulse output" encoders, which measure the position relative to the starting position but not the direction.
-- Absolute encoders, which provide the absolute position of a rotating shaft, without requiring a reference point.
-
-## Configuration
-
-To use an encoder, you need to add it to your machine's configuration.
-
-Go to your machine's **CONFIGURE** page, and add a model that supports your encoder.
-
-The following list shows the available encoder models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:encoder" type="encoder" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`incremental`](incremental-micro-rdk/) | A two phase encoder, which can measure the speed and direction of rotation in relation to a given reference point |
-| [`single`](single-micro-rdk/) | A single pin "pulse output" encoder which returns its relative position but no direction |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [encoder API](/reference/apis/components/encoder/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/encoder-table.md" >}}
-
-## Troubleshooting
-
-If your encoder is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your encoder model's documentation to ensure you have configured all required attributes.
-1. Check that all wires are securely attached to the correct pins.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the encoder there.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/operate/reference/components/motor/encoded-motor/" noimage="true" %}}
-{{< /cards >}}
-
-You can also use the encoder component with the following services:
-
-- [Data management service](/data/capture-sync/capture-and-sync-data/): To capture and sync the encoder's data
-- [Motion service](/operate/reference/services/motion/): To move machines or components of machines
-- [Navigation service](/operate/reference/services/navigation/): To navigate with GPS
diff --git a/docs/operate/reference/components/encoder/arduino.md b/docs/operate/reference/components/encoder/arduino.md
deleted file mode 100644
index a7e3ea96e7..0000000000
--- a/docs/operate/reference/components/encoder/arduino.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "Configure an Arduino Encoder"
-linkTitle: "arduino"
-type: "docs"
-description: "Configure an Arduino encoder."
-images: ["/icons/components/encoder.svg"]
-tags: ["encoder", "components"]
-draft: true
-aliases:
-  - /components/encoder/arduino/
-toc_hide: true
-# SMEs: Rand
----
-
-{{< tabs name="Configure an arduino Encoder" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `encoder` type, then select the `arduino` model.
-Enter a name or use the suggested name for your encoder and click **Create**.
-
-![Configuration of an Arduino encoder.](/components/encoder/configure-arduino.png)
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-encoder-name>",
-  "model": "arduino",
-  "api": "rdk:component:encoder",
-  "attributes": {
-    "board": "<your-board-name>",
-    "motor_name": "your-motor-name>",
-    "pins": {
-      "a": "<pin-number-on-board>",
-      "b": "<pin-number-on-board"
-    }
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `arduino` encoders:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | **Required** | The `name` of the board to which the encoder is wired. |
-| `motor_name` | string | **Required** | The `name` of the motor. |
-| `pins` | **Required** | object | A struct holding the names of the pins wired to the encoder: <ul> <li> <code>a</code>: {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} of one of the pins to which the encoder is wired. </li> <li> <code>b</code>: Required for two phase encoder. {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} for the second board pin to which the encoder is wired. </li> </ul> |
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/encoder.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/encoder/" customTitle="Encoder API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/encoder/fake.md b/docs/operate/reference/components/encoder/fake.md
deleted file mode 100644
index 3ee7145524..0000000000
--- a/docs/operate/reference/components/encoder/fake.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: "Configure a Fake Encoder"
-linkTitle: "fake"
-type: "docs"
-description: "Configure a fake encoder."
-images: ["/icons/components/encoder.svg"]
-tags: ["encoder", "components"]
-weight: 10
-aliases:
-  - "/components/encoder/fake/"
-component_description: "An encoder model for testing."
-toc_hide: true
-# SMEs: Rand
----
-
-The `fake` encoder is an encoder model for testing code without any hardware.
-
-{{< tabs name="Configure an fake encoder" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `encoder` type, then select the `fake` model.
-Enter a name or use the suggested name for your encoder and click **Create**.
-
-![Configuration of a fake encoder.](/components/encoder/configure-fake.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-encoder-name>",
-  "model": "fake",
-  "api": "rdk:component:encoder",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "myEncoder",
-  "model": "fake",
-  "api": "rdk:component:encoder",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for `fake` encoders.
-
-## Test the encoder
-
-Once your encoder is configured and your machine is connected, go to the [**CONTROL** tab](/manage/troubleshoot/teleoperate/default-interface/) and click on the encoder's dropdown panel.
-The ticks count is displayed.
-
-![Encoder control panel.](/components/encoder/control.png)
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/encoder.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/encoder/" customTitle="Encoder API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/encoder/incremental-micro-rdk.md b/docs/operate/reference/components/encoder/incremental-micro-rdk.md
deleted file mode 100644
index 7d879a4913..0000000000
--- a/docs/operate/reference/components/encoder/incremental-micro-rdk.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: "Configure an Incremental Encoder (Micro-RDK)"
-linkTitle: "incremental (Micro-RDK)"
-titleMustBeLong: true
-type: "docs"
-description: "Configure an incremental encoder."
-images: ["/icons/components/encoder.svg"]
-tags: ["encoder", "components"]
-aliases:
-  - /micro-rdk/encoder/incremental/
-  - /build/micro-rdk/encoder/incremental/
-  - /components/encoder/incremental-micro-rdk/
-micrordk_component: true
-toc_hide: true
-# SMEs: Rand
----
-
-Use the `incremental` encoder model to configure [a quadrature encoder](https://en.wikipedia.org/wiki/Incremental_encoder).
-
-Configuring an `incremental` encoder requires specifying the {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}} of the two pins on the board to which the encoder is wired.
-These two pins provide the phase outputs used to measure the speed and direction of rotation in relation to a given reference point.
-
-To be able to test the encoder as you configure it, connect the encoder to your microcontroller and power both on.
-Then, configure the encoder:
-
-{{< tabs name="Configure an incremental encoder" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `encoder` type, then select the `incremental` model.
-Enter a name or use the suggested name for your encoder and click **Create**.
-
-![Configuration of an incremental encoder.](/components/encoder/configure-incremental.png)
-
-Fill in and edit the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-encoder-name>",
-  "model": "incremental",
-  "api": "rdk:component:encoder",
-  "attributes": {
-    "board": "<your-board-name>",
-    "a": "<your-first-pin-number>",
-    "b": "<your-second-pin-number>"
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "myEncoder",
-      "model": "incremental",
-      "api": "rdk:component:encoder",
-      "attributes": {
-        "board": "local",
-        "a": "13",
-        "b": "11"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `incremental` encoders:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | **Required** | The `name` of the [board](/operate/reference/components/board/) to which the encoder is wired. |
-| `a` | string | **Required** | GPIO number of one of the pins to which the encoder is wired |
-| `b` | string | **Required** | GPIO number of the second board pin to which the encoder is wired |
-
-{{< readfile "/static/include/components/test-control/encoder-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/encoder.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/encoder/" customTitle="Encoder API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/encoder/incremental.md b/docs/operate/reference/components/encoder/incremental.md
deleted file mode 100644
index 0f5ba866c3..0000000000
--- a/docs/operate/reference/components/encoder/incremental.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: "Configure an Incremental Encoder"
-linkTitle: "incremental"
-type: "docs"
-description: "Configure an incremental encoder."
-images: ["/icons/components/encoder.svg"]
-tags: ["encoder", "components"]
-aliases:
-  - "/components/encoder/incremental/"
-component_description: "Supports a two phase encoder, which can measure the speed and direction of rotation in relation to a given reference point."
-toc_hide: true
-# SMEs: Rand
----
-
-Use the `incremental` encoder model to configure [a quadrature encoder](https://en.wikipedia.org/wiki/Incremental_encoder).
-
-Configuring an `incremental` encoder requires specifying the {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}} of the two pins on the board to which the encoder is wired.
-These two pins provide the phase outputs used to measure the speed and direction of rotation in relation to a given reference point.
-
-To be able to test the encoder as you configure it, connect the encoder to your machine's computer and power both on.
-Then, configure the encoder:
-
-{{< tabs name="Configure an incremental encoder" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `encoder` type, then select the `incremental` model.
-Enter a name or use the suggested name for your encoder and click **Create**.
-
-![Configuration of an incremental encoder.](/components/encoder/configure-incremental.png)
-
-Fill in and edit the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-encoder-name>",
-  "model": "incremental",
-  "api": "rdk:component:encoder",
-  "attributes": {
-    "board": "<your-board-name>",
-    "pins": {
-      "a": "<your-first-pin-number>",
-      "b": "<your-second-pin-number>"
-    }
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "pi",
-      "api": "rdk:component:board",
-      "attributes": {}
-    },
-    {
-      "name": "myEncoder",
-      "model": "incremental",
-      "api": "rdk:component:encoder",
-      "attributes": {
-        "board": "local",
-        "pins": {
-          "a": "13",
-          "b": "11"
-        }
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `incremental` encoders:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | **Required** | The `name` of the [board](/operate/reference/components/board/) to which the encoder is wired. |
-| `pins` | object | **Required** | A struct holding the names of the pins wired to the encoder: <ul> <li> <code>a</code>: {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} of one of the pins to which the encoder is wired. </li> <li> <code>b</code>: Required for two phase encoder. {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} for the second board pin to which the encoder is wired. </li><p>If the encoded motor does not operate as expected, the encoder pins might be configured in reverse, switch the <code>a</code> and <code>b</code> pin definitions in your incremental encoder attributes to reconfigure your encoded motor.</p> </ul> |
-
-Viam also supports a model of encoder called [`"single"`](../single/) which requires only one pin (`i`).
-
-{{< readfile "/static/include/components/test-control/encoder-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/encoder.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/encoder/" customTitle="Encoder API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/encoder/single-micro-rdk.md b/docs/operate/reference/components/encoder/single-micro-rdk.md
deleted file mode 100644
index d96301b775..0000000000
--- a/docs/operate/reference/components/encoder/single-micro-rdk.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: "Configure a Single Encoder (Micro-RDK)"
-linkTitle: "single (Micro-RDK)"
-type: "docs"
-description: "Configure a single encoder with a microcontroller."
-images: ["/icons/components/encoder.svg"]
-tags: ["encoder", "components"]
-aliases:
-  - /micro-rdk/encoder/single/
-  - /build/micro-rdk/encoder/single/
-  - /components/encoder/single-micro-rdk/
-micrordk_component: true
-toc_hide: true
-# SMEs: Rand
----
-
-A `single` encoder sends a signal from the rotating encoder over a single wire to one pin on the [board](/operate/reference/components/board/).
-The direction of spin is dictated by the [motor](/operate/reference/components/motor/) that has this encoder's name in its `encoder` attribute field.
-
-To be able to test the encoder as you configure it, connect the encoder to your machine's computer and power both on.
-Then, configure the encoder:
-
-{{< tabs name="Configure an single encoder" >}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-encoder-name>",
-  "model": "single",
-  "api": "rdk:component:encoder",
-  "attributes": {
-    "pin": <int>,
-    "dir_flip": <boolean>
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-encoder-name>",
-  "model": "single",
-  "api": "rdk:component:encoder",
-  "attributes": {
-    "pin": 22,
-    "dir_flip": false
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `single` encoders:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `pin` | object | **Required** | GPIO number of the pin to which the encoder is wired. |
-| `dir_flip` | boolean | **Required** | If the encoder's count should increment or decrement in its initial state before a [`SetPower()`](/reference/apis/components/motor/#setpower) call is made to an encoded [motor](/operate/reference/components/motor/). `true` implies decrement. |
-
-{{< readfile "/static/include/components/test-control/encoder-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/encoder.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/encoder/" customTitle="Encoder API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/encoder/single.md b/docs/operate/reference/components/encoder/single.md
deleted file mode 100644
index 09b1a986ed..0000000000
--- a/docs/operate/reference/components/encoder/single.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: "Configure a Single Encoder"
-linkTitle: "single"
-type: "docs"
-description: "Configure a single encoder."
-images: ["/icons/components/encoder.svg"]
-tags: ["encoder", "components"]
-aliases:
-  - "/components/encoder/single/"
-component_description: "A single pin 'pulse output' encoder which returns its relative position but no direction."
-toc_hide: true
-# SMEs: Rand
----
-
-A `single` encoder sends a signal from the rotating encoder over a single wire to one pin on the [board](/operate/reference/components/board/).
-The direction of spin is dictated by the [motor](/operate/reference/components/motor/) that has this encoder's name in its `encoder` attribute field.
-
-To be able to test the encoder as you configure it, connect the encoder to your machine's computer and power both on.
-Then, configure the encoder:
-
-{{< tabs name="Configure an single encoder" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `encoder` type, then select the `single` model.
-Enter a name or use the suggested name for your encoder and click **Create**.
-
-![Configuration of a single encoder.](/components/encoder/configure-single.png)
-
-Fill in and edit the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-encoder-name>",
-  "model": "single",
-  "api": "rdk:component:encoder",
-  "attributes": {
-    "board": "<your-board-name>",
-    "pins": {
-      "i": "<your-pin-number-on-board>"
-    }
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `single` encoders:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | **Required** | The `name` of the [board](/operate/reference/components/board/) to which the encoder is wired. |
-| `pins` | object | **Required** | A struct holding the name of the pin wired to the encoder: <ul> <li> <code>i</code>: {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} of the pin to which the encoder is wired. </li> </ul> |
-
-Viam also supports a model of encoder called [`"incremental"`](../incremental/) which uses two pins.
-
-{{< readfile "/static/include/components/test-control/encoder-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/encoder.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/encoder/" customTitle="Encoder API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/gantry/_index.md b/docs/operate/reference/components/gantry/_index.md
deleted file mode 100644
index 8b86a76e76..0000000000
--- a/docs/operate/reference/components/gantry/_index.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: "Gantry Component"
-linkTitle: "Gantry"
-childTitleEndOverwrite: "Gantry Component"
-no_list: true
-weight: 50
-type: "docs"
-description: "A mechanical system of linear rails that can precisely position an attached device."
-tags: ["gantry", "components"]
-icon: true
-images: ["/icons/components/gantry.svg"]
-modulescript: true
-aliases:
-  - "/components/gantry/"
-hide_children: true
-date: "2024-10-21"
-# SME: Rand
----
-
-<div class="td-max-width-on-larger-screens text-center">
-<img src="/components/gantry/gantry-illustration.png" style="width:300px" alt="Example of what a multi-axis robot gantry looks like as a black and white illustration of an XX YY mechanical gantry." class="alignright imgzoom">
-</div>
-
-The gantry component provides an API for coordinated control of one or more linear actuators.
-
-If you have a physical gantry, that is a mechanical system of linear actuators used to hold and position an [end effector](https://en.wikipedia.org/wiki/Robot_end_effector), use a gantry component.
-
-A 3D printer is an example of a three-axis gantry where each linear actuator can move the print head along one axis.
-
-Gantry components can only be controlled in terms of linear motion (you cannot rotate them).
-Each gantry can only move in one axis within the limits of the length of the linear rail.
-
-## Configuration
-
-To use a gantry, you need to add it to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your gantry.
-
-The following list shows the available gantry models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:gantry" type="gantry" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [gantry API](/reference/apis/components/gantry/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/gantry-table.md" >}}
-
-## Troubleshooting
-
-If your gantry is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your gantry model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the gamtry there.
-1. Disconnect and reconnect your gantry.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
-
-You can also use the gantry component with the following services:
-
-- [Motion service](/operate/reference/services/motion/): To move machines or components of machines
-- [Frame system service](/operate/reference/services/frame-system/): To configure the positions of your components
diff --git a/docs/operate/reference/components/gantry/fake.md b/docs/operate/reference/components/gantry/fake.md
deleted file mode 100644
index d905da2e6f..0000000000
--- a/docs/operate/reference/components/gantry/fake.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: "Configure a Fake Gantry"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake gantry."
-tags: ["gantry", "components"]
-icon: true
-images: ["/icons/components/gantry.svg"]
-aliases:
-  - "/components/gantry/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
-# SME: Rand
----
-
-Configure a `fake` gantry to test implementing a gantry component on your machine without any physical hardware:
-
-{{< tabs name="Configure a Fake Gantry" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `gantry` type, then select the `fake` model.
-Enter a name or use the suggested name for your gantry and click **Create**.
-
-![An example configuration for a fake gantry.](/components/gantry/fake-gantry-ui-config.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-fake-gantry-name>",
-  "model": "fake",
-  "api": "rdk:component:gantry",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for fake gantries.
-See [GitHub](https://github.com/viamrobotics/rdk/blob/main/components/gantry/fake/gantry.go) for API call return specifications.
-
-{{< readfile "/static/include/components/test-control/gantry-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/gantry.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/gantry/" customTitle="Gantry API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/gantry/multi-axis.md b/docs/operate/reference/components/gantry/multi-axis.md
deleted file mode 100644
index 45e80f3f67..0000000000
--- a/docs/operate/reference/components/gantry/multi-axis.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-title: "Configure a Multi-Axis Gantry"
-linkTitle: "multi-axis"
-weight: 80
-type: "docs"
-description: "Configure a multi-axis gantry."
-images: ["/icons/components/gantry.svg"]
-tags: ["gantry", "components"]
-aliases:
-  - "/components/gantry/multiaxis/"
-  - "/components/gantry/multi-axis/"
-component_description: "Supports a gantry with multiple linear rails. Composed of multiple single-axis gantries."
-toc_hide: true
-# SME: Rand, Martha
----
-
-Configure a `multi-axis` gantry to integrate a gantry made up of multiple [`single-axis`](/operate/reference/components/gantry/single-axis/) gantries into your machine.
-
-First, physically assemble the gantry and connect it to your machine's computer.
-Power both on.
-Next, configure each single-axis gantry that is part of the muti-axis gantry.
-Then, configure the multi-axis gantry:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `gantry` type, then select the `multi-axis` model.
-Enter a name or use the suggested name for your gantry and click **Create**.
-
-![Creation of a multi-axis gantry component.](/components/gantry/multi-axis-ui-config.png)
-
-Fill in the attributes as applicable to your gantry, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    ... // < INSERT YOUR MOTOR AND SINGLE-AXIS GANTRY CONFIGURATIONS >
-    {
-      "name": "<your-fake-gantry-name>",
-      "model": "multi-axis",
-      "api": "rdk:component:gantry",
-      "attributes": {
-          "subaxes_list": [
-              "<xaxis-name>",
-              "<yaxis-name>",
-              "<zaxis-name>"
-          ]
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "pi",
-      "api": "rdk:component:board"
-    },
-    {
-      "name": "xmotor",
-      "model": "gpiostepper",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "board": "local",
-        "pins": {
-          "dir": "11",
-          "pwm": "13",
-          "step": "15"
-        },
-        "stepperDelay": 50,
-        "ticksPerRotation": 200
-      }
-    },
-    {
-      "name": "ymotor",
-      "model": "gpiostepper",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "board": "local",
-        "pins": {
-          "dir": "16",
-          "pwm": "18",
-          "step": "22"
-        },
-        "stepperDelay": 50,
-        "ticksPerRotation": 200
-      }
-    },
-    {
-      "name": "zmotor",
-      "model": "gpiostepper",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "board": "local",
-        "pins": {
-          "dir": "29",
-          "pwm": "31",
-          "step": "33"
-        },
-        "stepperDelay": 50,
-        "ticksPerRotation": 200
-      }
-    },
-    {
-      "name": "xaxis",
-      "model": "single-axis",
-      "api": "rdk:component:gantry",
-      "attributes": {
-        "length_mm": 1000,
-        "board": "local",
-        "limit_pin_enabled_high": false,
-        "limit_pins": ["32", "36"],
-        "motor": "xmotor",
-        "gantry_rpm": 500,
-        "axis": {
-          "x": 1,
-          "y": 0,
-          "z": 0
-        }
-      }
-    },
-    {
-      "name": "yaxis",
-      "model": "single-axis",
-      "api": "rdk:component:gantry",
-      "attributes": {
-        "length_mm": 1000,
-        "board": "local",
-        "limit_pin_enabled_high": false,
-        "limit_pins": ["37", "38"],
-        "motor": "ymotor",
-        "gantry_rpm": 500,
-        "axis": {
-          "x": 0,
-          "y": 1,
-          "z": 0
-        }
-      }
-    },
-    {
-      "name": "zaxis",
-      "model": "single-axis",
-      "api": "rdk:component:gantry",
-      "attributes": {
-        "length_mm": 1000,
-        "board": "local",
-        "limit_pin_enabled_high": false,
-        "limit_pins": ["10", "12"],
-        "motor": "zmotor",
-        "gantry_rpm": 500,
-        "axis": {
-          "x": 0,
-          "y": 0,
-          "z": 1
-        }
-      },
-      "frame": {
-        "parent": "world",
-        "orientation": {
-          "type": "euler_angles",
-          "value": {
-            "roll": 0,
-            "pitch": 40,
-            "yaw": 0
-          }
-        },
-        "translation": {
-          "x": 0,
-          "y": 3,
-          "z": 0
-        }
-      }
-    },
-    {
-      "name": "my_multi-axis_gantry",
-      "model": "multi-axis",
-      "api": "rdk:component:gantry",
-      "attributes": {
-        "subaxes_list": ["xaxis", "yaxis", "zaxis"],
-        "move_simultaneously": "false"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% /tabs %}}
-
-The following attributes are available for `multi-axis` gantries:
-
-<!-- prettier-ignore -->
-| Attribute | Type | Required? | Description |
-| --------- | ---- | --------- | ----------- |
-| `subaxes_list` | array | **Required** | An array of the `name` of each of the sub-axes, the [`single-axis`](/operate/reference/components/gantry/single-axis/) gantries that make up the `multi-axis` gantry. |
-| `move_simultaneously` | boolean | Optional | A boolean indicating if the sub-axes should move together, or one at a time when `MoveToPosition` is called. <br> Default:  `false` |
-
-{{< readfile "/static/include/components/test-control/gantry-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/gantry.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/gantry/" customTitle="Gantry API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/gantry/single-axis.md b/docs/operate/reference/components/gantry/single-axis.md
deleted file mode 100644
index 71a1da0636..0000000000
--- a/docs/operate/reference/components/gantry/single-axis.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: "Configure a Single-Axis Gantry"
-linkTitle: "single-axis"
-weight: 70
-type: "docs"
-description: "Configure a single-axis gantry."
-images: ["/icons/components/gantry.svg"]
-tags: ["gantry", "components"]
-aliases:
-  - "/components/gantry/oneaxis/"
-  - "/components/gantry/single-axis/"
-component_description: "Supports a gantry with a singular linear rail."
-toc_hide: true
-# SME: Rand, Martha
----
-
-Configure a `single-axis` gantry to integrate a single-axis gantry into your machine.
-First, be sure to physically assemble the gantry and connect it to your machine's computer.
-Power both on.
-Also, configure any [motor components](/operate/reference/components/motor/) that are part of the gantry.
-Then, configure the gantry:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `gantry` type, then select the `single-axis` model.
-Enter a name or use the suggested name for your sensor and click **Create**.
-
-![Creation of a single-axis gantry component.](/components/gantry/single-axis-ui-config.png)
-
-Fill in the attributes as applicable to your gantry, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    // < Your motor config >
-    {
-      "name": "<your-single-axis-gantry-name>",
-      "model": "single-axis",
-      "api": "rdk:component:gantry",
-      "attributes": {
-        "motor": "<your-motor-name>",
-        "length_mm": <int>,
-        "mm_per_rev": <int>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% /tabs %}}
-
-The following attributes are available for `single-axis` gantries:
-
-<!-- prettier-ignore -->
-| Attribute | Type | Required? | Description |
-| --------- | ---- | --------- | ----------  |
-| `length_mm` | int | **Required** | Length of the axis of the gantry in millimeters. |
-| `motor` | string | **Required** | `name` of the [motor](/operate/reference/components/motor/) that moves the gantry's actuator. |
-| `board`  |  string | Optional | `name` of the [board](/operate/reference/components/board/) containing the limit switches and pins. If `limit_pins` exist, `board` is required. |
-| `limit_pins`  | object | Optional | The `boards`'s pins attached to the limit switches on either end. If the [motor](/operate/reference/components/motor/) used does not include an [encoder](/operate/reference/components/motor/encoded-motor/), `limit_pins` are required to be set. |
-| `limit_pin_enabled_high` | boolean | Optional | Whether the limit pins are enabled. <br> Default: `false` |
-| `mm_per_rev` | int | **Required** | How far the gantry moves (linear, distance in mm) per one revolution of the motor’s output shaft. This typically corresponds to Distance = PulleyDiameter * pi, or the pitch of a linear screw. |
-| `gantry_mm_per_sec` | int | Optional | The speed at which the gantry moves in millimeters per second. Used to calculate the gantry `motor`'s revolutions per minute (RPM). <br> Default: `100` RPM |
-
-{{< readfile "/static/include/components/test-control/gantry-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/gantry.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/gantry/" customTitle="Gantry API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/generic/_index.md b/docs/operate/reference/components/generic/_index.md
deleted file mode 100644
index 2dad5b2838..0000000000
--- a/docs/operate/reference/components/generic/_index.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: "Generic Component"
-linkTitle: "Generic"
-childTitleEndOverwrite: "Generic Component"
-weight: 55
-type: "docs"
-description: "A component that does not fit any of the other APIs."
-tags: ["generic", "components"]
-icon: true
-images: ["/icons/components/generic.svg"]
-no_list: true
-modulescript: true
-aliases:
-  - "/components/generic/"
-  - /micro-rdk/generic/
-  - /build/micro-rdk/generic/
-hide_children: true
-date: "2024-10-21"
-# SMEs:
----
-
-Generic components provide an API for running model-specific commands using [`DoCommand`](/reference/apis/components/generic/#docommand).
-
-If you have a physical device or a program that does not fit into any of the provided [components APIs](/reference/apis/#component-apis), use a generic component.
-
-For example, if you want to use an LED display, you need functionality that isn't currently exposed in an existing API.
-Instead, you can use the generic component API to add support for your unique type of hardware, like LED displays, to your machine.
-
-You should use the generic component for {{< glossary_tooltip term_id="modular-resource" text="modular resources" >}} that represent a unique type of hardware.
-If you are adding new high-level software functionality, rather than supporting new hardware components, use the [generic service](/operate/reference/components/generic/) instead.
-
-{{% alert title="Important" color="note" %}}
-
-The generic component API only supports the `DoCommand` method.
-If you use the generic API, your module needs to define any and all component functionality and pass it through `DoCommand`.
-
-Whenever possible, it is best to use an [existing component API](/reference/apis/#component-apis) instead of generic so that you do not have to replicate code.
-If you want to use most of an existing API but need just a few other functions, try using the `DoCommand` endpoint and extra parameters to add custom functionality to an existing API, instead of using the generic component.
-
-{{% /alert %}}
-
-{{% alert title="Example usage" color="tip" %}}
-
-See [Deploy control logic](/operate/modules/write-a-logic-module/) for an example of how to use the generic component API, including how to call `DoCommand()` from the SDKs or the web UI.
-
-{{% /alert %}}
-
-## Configuration
-
-To use a generic component, check whether one of the following models supports it.
-
-For configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:generic" type="generic" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-If your `viam-micro-server` machine includes a resource that isn't a [base](/operate/reference/components/base/), [board](/operate/reference/components/board/),[encoder](/operate/reference/components/encoder/), [movement sensor](/operate/reference/components/movement-sensor/), [motor](/operate/reference/components/motor/), or [servo](/operate/reference/components/servo/), you can create a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}} to add support for it as a custom model of the generic API.
-
-{{< alert title="Important" color="note" >}}
-`viam-micro-server` works differently from the RDK, so creating modular resources for it is different.
-Refer to the [Micro-RDK Module Template on GitHub](https://github.com/viamrobotics/micro-rdk/tree/main/templates/module) for information on how to create custom resources for your `viam-micro-server` machine.
-You will need to [recompile and flash your ESP32 yourself](/operate/install/setup/) instead of using Viam's prebuilt binary and installer.
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [generic API](/reference/apis/components/generic/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/generic_component-table.md" >}}
-
-## Troubleshooting
-
-If your generic component is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your generic component model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the generic component there.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/generic/fake.md b/docs/operate/reference/components/generic/fake.md
deleted file mode 100644
index 5be945be98..0000000000
--- a/docs/operate/reference/components/generic/fake.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: "Configure a Fake Generic Component"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake generic component."
-tags: ["generic", "components"]
-aliases:
-  - "/components/generic/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
----
-
-Configure a `fake` generic component to test implementing a generic component on your machine without any physical hardware:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `generic` type, then select the `fake` model.
-Enter a name or use the suggested name for your generic component and click **Create**.
-
-![An example configuration for a fake generic component.](/components/generic/fake-generic-ui-config.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-fake-generic-component-name>",
-  "model": "fake",
-  "api": "rdk:component:generic",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for the `fake` generic component.
-See [GitHub](https://github.com/viamrobotics/rdk/blob/main/components/generic/fake/generic.go) for API call return specifications.
-
-{{< readfile "/static/include/components/test-control/generic-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/generic.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/generic/" customTitle="Generic API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/gripper/_index.md b/docs/operate/reference/components/gripper/_index.md
deleted file mode 100644
index ac309aed1b..0000000000
--- a/docs/operate/reference/components/gripper/_index.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: "Gripper Component"
-linkTitle: "Gripper"
-childTitleEndOverwrite: "Gripper Component"
-weight: 60
-type: "docs"
-description: "A gripper is a robotic grasping device that can open and close."
-tags: ["gripper", "components"]
-icon: true
-images: ["/icons/components/gripper.svg"]
-no_list: true
-modulescript: true
-aliases:
-  - "/components/gripper/"
-hide_children: true
-date: "2024-10-21"
-# SMEs: Bucket Team
----
-
-The gripper component provides an API for opening and closing a device.
-
-If you have a robotic grasping device that can open and close, use a gripper component.
-
-## Configuration
-
-To use a robotic gripper, you need to add it to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your gripper.
-
-The following list shows the available gripper models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:gripper" type="gripper" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [gripper API](/reference/apis/components/gripper/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/gripper-table.md" >}}
-
-## Troubleshooting
-
-If your gripper is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your gripper model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the gripper there.
-1. Disconnect and reconnect your gripper.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/tutorials/services/plan-motion-with-arm-gripper" noimage="true" %}}
-{{< /cards >}}
-
-You can also use the gripper component with the following services:
-
-- [Motion service](/operate/reference/services/slam/): To move machines or components of machines
-- [Frame system service](/operate/reference/services/navigation/): To configure the positions of your components
diff --git a/docs/operate/reference/components/gripper/fake.md b/docs/operate/reference/components/gripper/fake.md
deleted file mode 100644
index aed8b8c6ad..0000000000
--- a/docs/operate/reference/components/gripper/fake.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: "Configure a Fake Gripper"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake gripper."
-tags: ["gripper", "components"]
-icon: true
-images: ["/icons/components/gripper.svg"]
-aliases:
-  - "/components/gripper/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
-# SME: Rand
----
-
-Configure a `fake` gripper to test implementing a gripper on your machine without any physical hardware:
-
-{{< tabs name="Configure a Fake Gripper" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `gripper` type, then select the `fake` model.
-Enter a name or use the suggested name for your gripper and click **Create**.
-
-![An example configuration for a fake gripper.](/components/gripper/fake-gripper-ui-config.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-fake-gripper-name>",
-  "model": "fake",
-  "api": "rdk:component:gripper",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for fake grippers.
-See [GitHub](https://github.com/viamrobotics/rdk/blob/main/components/gripper/fake/gripper.go) for API call return specifications.
-
-{{< readfile "/static/include/components/test-control/gripper-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/gripper.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/gripper/" customTitle="Gripper API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/tutorials/services/plan-motion-with-arm-gripper/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/input-controller/_index.md b/docs/operate/reference/components/input-controller/_index.md
deleted file mode 100644
index 261cde8e49..0000000000
--- a/docs/operate/reference/components/input-controller/_index.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: "Input Controller Component"
-linkTitle: "Input Controller"
-weight: 60
-type: "docs"
-no_list: true
-description: "An input controller, like a gamepad or joystick, is a device humans use to control a machine's actions."
-tags: ["input controller", "components"]
-icon: true
-images: ["/icons/components/controller.svg"]
-modulescript: true
-aliases:
-  - "/components/input-controller/"
-hide_children: true
-date: "2024-10-21"
-# SME: James
----
-
-The input controller API provides an API for configuring callbacks for events, allowing you to configure input devices to control your machines.
-
-If you have a keyboard, mouse, elevator button panel, light power switch, joystick, gamepad, or video game controllers with which you want to control a robotic base, use an input controller component.
-
-This component supports devices like gamepads and joysticks that contain one or more [`Control`s](/reference/apis/components/input-controller/#control-field) representing the individual axes and buttons on the device.
-To use the controller's inputs, you must [register callback functions](/reference/apis/components/input-controller/#registercontrolcallback) to the [`Control`s](/reference/apis/components/input-controller/#control-field) with the [`input` API](/reference/apis/components/input-controller/).
-
-The callback functions can then handle the [Events](/reference/apis/components/input-controller/#getevents) that are sent when the `Control` is activated or moved.
-For example, when a specific button is pushed, the callback function registered to it can move another component, or print a specific output.
-
-The [base remote control service](/operate/reference/services/base-rc/) implements an input controller as a remote control for a base.
-
-## Configuration
-
-To use an input controller to control your machine's actions, you need to add it to your machine's configuration.
-
-Go to your machine's **CONFIGURE** page, and add a model that supports your input controller.
-
-The following list shows the available input controller models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:input_controller" type="input_controller" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [input controller API](/reference/apis/components/input-controller/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/input_controller-table.md" >}}
-
-## Troubleshooting
-
-If your input controller is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your input controller model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the input controller there.
-1. Disconnect and reconnect your input controller.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/tutorials/control/gamepad/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/input-controller/fake.md b/docs/operate/reference/components/input-controller/fake.md
deleted file mode 100644
index 1fb4fce05d..0000000000
--- a/docs/operate/reference/components/input-controller/fake.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: "Configure a Fake Input Controller for Testing"
-linkTitle: "fake"
-weight: 30
-type: "docs"
-description: "Configure a fake input controller for testing."
-images: ["/icons/components/controller.svg"]
-tags: ["input controller", "components"]
-aliases:
-  - "/components/input-controller/fake/"
-component_description: "A model for testing, with no physical hardware."
-toc_hide: true
-# SMEs: James
----
-
-Configuring a `fake` input controller allows you to test an input controller communicating with your machine, without any physical hardware.
-
-This controller can have [Controls](/reference/apis/components/input-controller/#control-field) defined in `attributes`, as seen in the "JSON Template" tab below.
-However, these Controls only ever return a single `PositionChangeAbs` event on the X axis, with the [Event.value](/reference/apis/components/input-controller/#event-object) stuck at 0.7.
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `input_controller` type, then select the `fake` model.
-Enter a name or use the suggested name for your input controller and click **Create**.
-
-![An example configuration for a fake input controller component.](/components/input-controller/fake-input-controller-ui-config.png)
-
-Edit the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-fake-input-controller>",
-      "model": "fake",
-      "api": "rdk:component:input_controller",
-      "attributes": {
-        "controls": [
-          "AbsoluteX",
-          "AbsoluteY",
-          "AbsoluteZ"
-        ],
-        "event_value": <float>,
-        "callback_delay_sec": <float>
-      }
-    }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `fake` input controllers:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `callback_delay_sec` | float | **Required** | The number of seconds between callbacks getting triggered. Random between 1 and 2 if not specified. `0` is not valid and will be overwritten by a random delay. |
-| `event_value` | float | Optional | Set the value of events returned. Random between -1 and 1 if not specified. |
-| `controls` | array | Optional | Set the [Controls](/reference/apis/components/input-controller/#control-field) that are present on the controller. |
-
-{{< readfile "/static/include/components/test-control/input-controller-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/input-controller.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/input-controller/" customTitle="Input controller API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/tutorials/control/gamepad/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/input-controller/gamepad.md b/docs/operate/reference/components/input-controller/gamepad.md
deleted file mode 100644
index 70b1e38904..0000000000
--- a/docs/operate/reference/components/input-controller/gamepad.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: "Configure a Linux-supported Gamepad"
-linkTitle: "gamepad"
-weight: 30
-type: "docs"
-description: "Configure a linux-supported gamepad as an input controller."
-images: ["/icons/components/controller.svg"]
-tags: ["input controller", "components"]
-aliases:
-  - "/components/input-controller/gamepad/"
-component_description: "Supports X-box, Playstation, and similar controllers with Linux support."
-toc_hide: true
-# SMEs: James
----
-
-Configuring a `gamepad` input controller allows you to use a Linux-supported gamepad as a device to communicate with your machine.
-Linux supports most standard gamepads, such as PlayStation or Xbox type game controllers, as well as many joysticks, racing wheels, and more.
-
-To be able to test your gamepad as you configure it, physically connect your gamepad to your machine's computer and turn both on.
-Then, configure the controller:
-
-{{< tabs name="Configure a `gamepad` input controller" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `input_controller` type, then select the `gamepad` model.
-Enter a name or use the suggested name for your input controller and click **Create**.
-
-![An example configuration for a linux-based gamepad input controller component](/components/input-controller/gamepad-input-controller-ui-config.png)
-
-Edit the attributes as applicable to your input controller, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name":  "<your-gamepad-input-controller>",
-      "model": "gamepad",
-      "api": "rdk:component:input_controller",
-      "attributes": {
-        "dev_file": "<string>",
-        "auto_reconnect": <boolean>
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `gamepad` input controllers:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `dev_file` | string | Optional | If `dev_file` is left blank or not included, `viam-server` will search and use the first gamepad it finds that's connected to the computer controlling your machine. If you want to specify a device, give the absolute path to the input device event file. For example: `/dev/input/event42`. |
-| `auto_reconnect` | boolean | Optional | Applies to both remote (gRPC) and local (Bluetooth or direct USB connected) devices. If set to `true`, `viam-server` tries to (re)connect the device automatically. It waits for a device to connect during a machine's start-up. If set to false (default) then start-up fails if a device is not already connected. |
-
-{{< readfile "/static/include/components/test-control/input-controller-control.md" >}}
-
-## Work in progress models
-
-Mappings are currently available for a wired XBox 360 controller, and wireless XBox Series X|S, along with the 8bitdo Pro 2 Bluetooth gamepad (which works great with the Raspberry Pi).
-
-The XBox controllers emulate an XBox 360 gamepad when in wired mode, as does the 8bitdo.
-
-Because of that, any unknown gamepad is mapped as an XBox 360.
-
-If you have another controller that you want to use to control your machine, feel free to submit a PR on [GitHub](https://github.com/viamrobotics/rdk/blob/main/components/input/input.go) with new mappings.
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/input-controller.md" >}}
-
-{{% expand "Not able to see a dropdown menu?" %}}
-If you are not able to see a dropdown menu with the name of your controller appear in the **CONTROL** tab, try specifying the `dev_file` attribute to match the exact path to your device.
-You can also try setting `auto_reconnect` to `True`.
-{{% /expand%}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/input-controller/" customTitle="Input controller API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/tutorials/control/gamepad/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/input-controller/gpio.md b/docs/operate/reference/components/input-controller/gpio.md
deleted file mode 100644
index 9179c7c5b8..0000000000
--- a/docs/operate/reference/components/input-controller/gpio.md
+++ /dev/null
@@ -1,230 +0,0 @@
----
-title: "Configure a GPIO/ADC-Based Input Controller"
-linkTitle: "gpio"
-weight: 30
-type: "docs"
-description: "Configure a GPIO- or ADC-based device as an input controller."
-images: ["/icons/components/controller.svg"]
-tags: ["input controller", "components"]
-aliases:
-  - "/components/input-controller/gpio/"
-component_description: "Customizable GPIO/ADC based device using a board component."
-toc_hide: true
-# SMEs: James
----
-
-Configure a `gpio` input controller to use a GPIO- or ADC-based device to communicate with your machine.
-
-To be able to test your controller as you configure it, physically connect your controller to your machine's computer and turn both on.
-Then, configure the controller:
-
-{{< tabs name="Configure a `gpio` input controller" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `input_controller` type, then select the `gpio` model.
-Enter a name or use the suggested name for your input controller and click **Create**.
-
-![An example configuration for a GPIO input controller component](/components/input-controller/gpio-input-controller-ui-config.png)
-
-Click **JSON** to edit buttons and axes.
-Copy and paste the following attribute template into the JSON editor.
-Then remove and fill in the attributes as applicable to your input controller, according to the table below.
-
-{{< tabs >}}
-{{% tab name="Attributes template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "board": "<your-board-name>",
-  "buttons": {
-    "<your-button-name>": {
-      "control": "<button-control-name>",
-      "invert": <boolean>,
-      "debounce_msec": <int>
-    }
-  },
-  "axes": {
-    "<your-axis-name>": {
-      "control": "<axis-control-name>",
-      "min": <int>,
-      "max": <int>,
-      "poll_hz": <int>,
-      "deadzone": <int>,
-      "min_change": <int>,
-      "bidirectional": <boolean>,
-      "invert": <boolean>
-    }
-  },
-  "depends_on": ["<your-board-name>"]
-}
-```
-
-You can also select **board** in the builder editing mode to clarify the board you want to configure with this input controller.
-
-{{% /tab %}}
-{{% tab name="Attributes example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "board": "piboard",
-  "buttons": {
-    "interrupt1": {
-      "control": "ButtonNorth",
-      "invert": false,
-      "debounce_msec": 5
-    },
-    "interrupt2": {
-      "control": "ButtonSouth",
-      "invert": true,
-      "debounce_msec": 5
-    }
-  },
-  "axes": {
-    "analog1": {
-      "control": "AbsoluteX",
-      "min": 0,
-      "max": 1023,
-      "poll_hz": 50,
-      "deadzone": 30,
-      "min_change": 5,
-      "bidirectional": false,
-      "invert": false
-    },
-    "analog2": {
-      "control": "AbsoluteY",
-      "min": 0,
-      "max": 1023,
-      "poll_hz": 50,
-      "deadzone": 30,
-      "min_change": 5,
-      "bidirectional": true,
-      "invert": true
-    }
-  },
-  "depends_on": ["piboard"]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-gpio-input-controller-name>",
-      "model": "gpio",
-      "api": "rdk:component:input_controller",
-      "attributes": {
-        "board": "<your-board-name>",
-        "buttons": {
-          "<your-button-name>": {
-            "control": "<button-control-name>",
-            "invert": <boolean>,
-            "debounce_msec": <int>
-          }
-        },
-        "axes": {
-          "<your-axis-name>": {
-            "control": "<axis-control-name>",
-            "min": <int>,
-            "max": <int>,
-            "poll_hz": <int>,
-            "deadzone": <int>,
-            "min_change": <int>,
-            "bidirectional": <boolean>,
-            "invert": <boolean>
-          }
-        }
-      },
-      "depends_on": ["<your-board-name>"]
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "my_gpio_ic",
-      "model": "gpio",
-      "api": "rdk:component:input_controller",
-      "attributes": {
-        "board": "piboard",
-        "buttons": {
-          "interrupt1": {
-            "control": "ButtonNorth",
-            "invert": false,
-            "debounce_msec": 5
-          },
-          "interrupt2": {
-            "control": "ButtonSouth",
-            "invert": true,
-            "debounce_msec": 5
-          }
-        },
-        "axes": {
-          "analog1": {
-            "control": "AbsoluteX",
-            "min": 0,
-            "max": 1023,
-            "poll_hz": 50,
-            "deadzone": 30,
-            "min_change": 5,
-            "bidirectional": false,
-            "invert": false
-          },
-          "analog2": {
-            "control": "AbsoluteY",
-            "min": 0,
-            "max": 1023,
-            "poll_hz": 50,
-            "deadzone": 30,
-            "min_change": 5,
-            "bidirectional": true,
-            "invert": true
-          }
-        }
-      },
-      "depends_on": ["piboard"]
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `gpio` input controllers:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | **Required**| The name of the board component with GPIO or ADC pins to use as the controlling device. |
-| `buttons` | object | **Required** | The [Buttons](/reference/apis/components/input-controller/#button-controls) available for control. These should be connected to the GPIO/ADC board. <br><br> <b>Each button has the following fields:</b> <br><ul><li><code>name</code>: Name of the Digital Interrupt the button/switch is connected to, as configured on the board component.</li><li><code>control</code>: The [Control](/reference/apis/components/input-controller/#control-field) type to use when reporting events as this button's state is changed.</li><li><code>invert</code>: Boolean indicating if the digital input (high/low) should be inverted when reporting button Control value indicating button state.<br> This option is given because digital switches vary between high, `1`, and low, `0`, as their default at rest.<ul><li>*true:* `0` is pressed, and `1` is released.</li><li>*false (default):* `0` is released, and `1` is pressed.</li></ul></li><li><code>debounce_ms</code>: How many milliseconds to wait for the interrupt to settle. This is needed because some switches can be electrically noisy.</li></ul> |
-| `axes` | object | **Required** | The [Axes](/reference/apis/components/input-controller/#axis-controls) available for control. These should be connected to the GPIO/ADC board.<br><br>**Each axis has the following fields:**<ul><li><code>name</code>: Name of the Analog Reader that reports ADC values for the axis Control, as configured on the board component.</li><li><code>control</code>: The [Control](/reference/apis/components/input-controller/#control-field) type to use when reporting events as this axis's position is changed.</li><li><code>min</code>: The minimum ADC value that the analog reader can report as this axis's position changes. </li><li><code>max</code>: The maximum ADC value that the analog reader can report as this axis's position changes.</li><li><code>deadzone</code>: The absolute ADC value change from the neutral `0` point to still consider as a neutral position. This option is given so tiny wiggles on loose controls don't result in events being reported.</li><li><code>min_change</code>: The minimum absolute ADC value change from the previous ADC value reading that can occur before reporting a new [`PositionChangeAbs Event`](/reference/apis/components/input-controller/#event-object). This option is given so tiny wiggles on loose controls don't result in events being reported.</li><li><code>bidirectional</code>: Boolean indicating if the axis changes position in 1 direction, like on an analog trigger or pedal, or 2, like on an analog control stick.<ul><li>*true:* The axis should report center, `0`, as halfway between the min/max ADC values.</li><li>*false:* `0` is still the neutral point of the axis, but only positive change values can be reported.</li></ul></li><li><code>poll_hz</code>: How many times per second to check for a new ADC reading that can generate an event.</li><li><code>invert</code>: Boolean indicating if the direction of the axis should be flipped when translating ADC value readings to the axis Control value indicating position change.<ul><li>*true:* flips the direction of the axis so that the minimum ADC value is reported as the maximum axis Control value.</li><li>*false:* keeps the direction of the axis the same, so that the minimum ADC value is reported as the minimum axis Control value.</li></ul></li></ul> |
-
-{{< readfile "/static/include/components/test-control/input-controller-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/input-controller.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/input-controller/" customTitle="Input controller API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/tutorials/control/gamepad/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/input-controller/mux.md b/docs/operate/reference/components/input-controller/mux.md
deleted file mode 100644
index dc9e158184..0000000000
--- a/docs/operate/reference/components/input-controller/mux.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: "Configure a Mux Input Controller"
-linkTitle: "mux"
-weight: 30
-type: "docs"
-description: "Configure a mux input controller to combine one or more input controllers."
-images: ["/icons/components/controller.svg"]
-tags: ["input controller", "components"]
-aliases:
-  - "/components/input-controller/mux/"
-component_description: "Supports multiplexed controllers, combining multiple sources of input."
-toc_hide: true
-# SMEs: James
----
-
-Configuring a `mux` (multiplexed) input controller allows you to combine one or more controllers into a single virtual controller.
-
-This lets you control a machine from different locations, such as the web and a locally connected gamepad, or use multiple controllers as one device.
-
-For example, you could use a joystick alongside a numpad.
-
-## Configuration
-
-To combine multiple controllers into a `mux` controller, you must first configure each controller individually.
-
-{{< tabs name="Configure a `mux` input controller" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `input_controller` type, then select the `mux` model.
-Enter a name or use the suggested name for your input controller and click **Create**.
-
-![An example configuration for a multiplexed input controller component](/components/input-controller/mux-input-controller-ui-config.png)
-
-Enter the name of each source input controller in `sources`.
-
-Also, select each of the source input controllers in the **Depends on** dropdown menu.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-mux-input-controller-name>",
-      "model": "mux",
-      "api": "rdk:component:input_controller",
-      "attributes": {
-        "sources": [
-          "<your-gamepad-input-controller-name",
-          "<your-other-gamepad-input-controller-name>"
-        ]
-      },
-      "depends_on": [
-        "<your-gamepad-input-controller-name>",
-        "<your-other-gamepad-input-controller-name>"
-      ]
-    }
-    <...CONFIGS FOR THE INDIVIDUAL INPUT CONTROLLERS...>
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-The following example configuration combines a `gamepad` and a `webgamepad` controller:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "my-combined-controller",
-      "model": "mux",
-      "api": "rdk:component:input_controller",
-      "attributes": {
-        "sources": ["myGamepad", "WebGamepad"]
-      },
-      "depends_on": ["myGamepad", "WebGamepad"]
-    },
-    {
-      "name": "myGamepad",
-      "model": "gamepad",
-      "api": "rdk:component:input_controller",
-      "attributes": {
-        "auto_reconnect": true
-      },
-      "depends_on": []
-    },
-    {
-      "name": "WebGamepad",
-      "model": "webgamepad",
-      "api": "rdk:component:input_controller",
-      "attributes": {},
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `mux` input controllers:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `sources` | array | **Required** | The `name` of every controller component you wish to combine input from. |
-
-{{% alert title="Important" color="note" %}}
-You must put each controller's `name` that you add in `sources` in `depends_on`.
-This tells the program loading the config to fully load the source components first.
-{{% /alert %}}
-
-{{< readfile "/static/include/components/test-control/input-controller-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/input-controller.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/input-controller/" customTitle="Input controller API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/tutorials/control/gamepad/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/input-controller/webgamepad.md b/docs/operate/reference/components/input-controller/webgamepad.md
deleted file mode 100644
index 30a4b9de3a..0000000000
--- a/docs/operate/reference/components/input-controller/webgamepad.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: "Configure a Web Gamepad"
-linkTitle: "webgamepad"
-weight: 30
-type: "docs"
-description: "Configure a web-based gamepad as an input controller."
-images: ["/icons/components/controller.svg"]
-tags: ["input controller", "components"]
-aliases:
-  - "/components/input-controller/webgamepad/"
-component_description: "Supports a remote, web based gamepad."
-toc_hide: true
-# SMEs: James
----
-
-Configuring a `webgamepad` input controller allows you to use a web-based gamepad as a device to communicate with your machine.
-
-{{% alert title="Important" color="note" %}}
-You **must** use "WebGamepad" as the `name` of the web gamepad controller.
-This restriction will be removed in the future.
-{{% /alert %}}
-
-To be able to test your gamepad as you configure it, physically connect your gamepad to your machine's computer and turn both on.
-Then, configure the controller.
-
-## Configuration
-
-Use the following configuration for an input controller of model `webgamepad`:
-
-{{< tabs name="Configure a `webgamepad` input controller" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `input_controller` type, then select the `webgamepad` model.
-Enter the name `WebGamepad` and click **Create**.
-
-![An example configuration for a web-based gamepad input controller component](/components/input-controller/webgamepad-input-controller-ui-config.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "WebGamepad",
-      "model": "webgamepad",
-      "api": "rdk:component:input_controller",
-      "attributes": {},
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{< readfile "/static/include/components/test-control/input-controller-control.md" >}}
-
-{{% alert title="Important" color="note" %}}
-You have to press a button or move a stick on your gamepad for the browser to report the gamepad.
-For your security, the browser won't report a gamepad until an input has been sent.
-{{% /alert %}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/input-controller.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/input-controller/" customTitle="Input controller API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/tutorials/control/gamepad/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/motor/_index.md b/docs/operate/reference/components/motor/_index.md
deleted file mode 100644
index 2b77a6e444..0000000000
--- a/docs/operate/reference/components/motor/_index.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: "Motor Component"
-linkTitle: "Motor"
-childTitleEndOverwrite: "Motor Component"
-weight: 70
-type: "docs"
-description: "A motor is a rotating machine that transforms electrical energy into mechanical energy."
-tags: ["motor", "components"]
-icon: true
-images: ["/icons/components/motor.svg"]
-no_list: true
-modulescript: true
-aliases:
-  - "/components/motor/"
-  - /micro-rdk/motor/
-  - /build/micro-rdk/motor/
-hide_children: true
-date: "2024-10-21"
-# SME: Rand
----
-
-The motor component provides an API for operating a motor or getting its current status.
-
-If you have a device that converts electricity into rotary motion, such as a brushed DC motor, a brushless DC motor, or a stepper motor, configure it as a motor component.
-
-If you have a hobby servo, configure it as a [servo component](/operate/reference/components/servo/) instead.
-
-## Configuration
-
-To use a motor, you need to add it to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your motor and its motor driver.
-
-The following list shows the available motor models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:motor" type="motor" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`gpio`](./gpio-micro-rdk/) | [Standard brushed or brushless DC motor](https://en.wikipedia.org/wiki/DC_motor) |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [motor API](/reference/apis/components/motor/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/motor-table.md" >}}
-
-## Troubleshooting
-
-If your motor is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your motor model's documentation to ensure you have configured all required attributes.
-1. Check that all wires are securely attached to the correct pins.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the motor there.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/motor/dmc4000.md b/docs/operate/reference/components/motor/dmc4000.md
deleted file mode 100644
index 667584a49c..0000000000
--- a/docs/operate/reference/components/motor/dmc4000.md
+++ /dev/null
@@ -1,285 +0,0 @@
----
-title: "Configure a DMC4000-Controlled Motor"
-linkTitle: "DMC4000"
-weight: 60
-type: "docs"
-description: "Configure a stepper motor controlled by a DMC-40x0 series motion controller."
-images: ["/icons/components/motor.svg"]
-aliases:
-  - "/components/motor/dmc4000/"
-component_description: "Stepper motor driven by a DMC-40x0 series motion controller."
-# SMEs: Rand, James
-toc_hide: true
----
-
-{{< alert title="Note" color="note" >}}
-A private module exists that supports the DMC4000 motor controller.
-If you would like to use this controller with Viam, contact [Viam support](mailto:support@viam.com).
-{{< /alert >}}
-
-The `DMC4000` model supports stepper motors controlled by [DMC-40x0 series motion controllers](https://www.galil.com/motion-controllers/multi-axis/dmc-40x0).
-
-Whereas a basic low-level stepper driver supported by the [`gpiostepper` model](/operate/reference/components/motor/gpiostepper/) sends power to a stepper motor based on PWM signals from GPIO pins, the DMC40x0 motion controller has many motion control features.
-When using it, you do not need to configure a [board component](/operate/reference/components/board/) because it handles computation and signal creation on the motion controller itself.
-
-The DMC-40x0 controller can drive a variety of motor types, but the built-in Viam implementation supports only stepper motors at this time.
-You can drive other types of motors with Viam and the DMC-40x0 controller by creating a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}} to add support for it.
-
-Physically connect your motor to the DMC controller, and connect the controller to your machine's computer.
-Power both on.
-Then, configure the motor:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `motor` type, then select the `DMC4000` model.
-Enter a name or use the suggested name for your motor and click **Create**.
-
-![A DMC4000 motor config with the attributes configured per the JSON on the next tab in this doc.](/components/motor/dmc4000-config-ui.png)
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "<your-motor-name>",
-      "model": "DMC4000",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "amplifier_gain": <int>,
-        "low_current": <int>,
-        "ticks_per_rotation": <int>,
-        "serial_path": <string>,
-        "controller_axis": "<your-motion-controller-axis-label>",
-        "home_rpm": <int>,
-        "max_rpm": <float>,
-        "max_acceleration_rpm_per_sec": <float>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-Example configuration for a stepper motor controlled by a DMC-40x0 motion controller:
-
-```json
-{
-  "components": [
-    {
-      "name": "my-dmc-motor",
-      "model": "DMC4000",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "amplifier_gain": 3,
-        "low_current": 1,
-        "ticks_per_rotation": 200,
-        "serial_path": "/dev/serial/by-path/usb-0:1.1:1.0",
-        "controller_axis": "A",
-        "home_rpm": 70,
-        "max_rpm": 300
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-The `"serial_path"` filepath used in this example is specific to serial devices connected to Linux systems.
-The `"serial_path"` filepath on a macOS system might resemble <file>"/dev/ttyUSB0"</file> or <file>"/dev/ttyS0"</file>.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `DMC4000` motors:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-|`amplifier_gain` | int | **Required** | Set the [per phase current](https://www.galil.com/download/comref/com4103/index.html#amplifier_gain.html) (when using stepper amp). |
-| `low_current` | int | **Required** | Reduce the [hold current](https://www.galil.com/download/comref/com4103/index.html#low_current_stepper_mode.html). |
-| `ticks_per_rotation` | int | **Required** | Number of full steps in a rotation. 200 (equivalent to 1.8 degrees per step) is very common. If your data sheet specifies this in terms of degrees per step, divide 360 by that number to get ticks per rotation. |
-| `serial_path` | string | Optional | The full filesystem path to the serial device, starting with <file>/dev/</file>. To find your serial device path, first connect the serial device to your machine, then:<ul><li>On Linux, run <code>ls /dev/serial/by-path/\*</code> to show connected serial devices, or look for your device in the output of <code>sudo dmesg \| grep tty</code>. Example: <code>"/dev/serial/by-path/usb-0:1.1:1.0"</code>.</li><li>On macOS, run <code>ls /dev/tty\* \| grep -i usb</code> to show connected USB serial devices, <code>ls /dev/tty\*</code> to browse all devices, or look for your device in the output of <code>sudo dmesg \| grep tty</code>. Example: <code>"/dev/ttyS0"</code>.</li></ul><br>If you do not provide a `serial_path`, the driver will attempt to auto-detect the path to your serial device. |
-| `controller_axis` | string | **Required** | Physical port label (A-H); select which "axis" the motor is wired to on the controller. |
-| `home_rpm` | int | **Required** | Set speed in revolutions per minute (RPM) that the motor will turn when executing a Home() command (using  DoCommand()). |
-| `dir_flip` | bool | Optional | Flip the direction of the signal sent if there is a DIR pin. |
-| `max_rpm` | float | Optional | Set a limit on maximum revolutions per minute that the motor can be run at. |
-| `max_acceleration_rpm_per_sec` | float | Optional | Set the maximum revolutions per minute (RPM) per second acceleration limit. |
-
-Refer to your motor and motor driver data sheets for specifics.
-
-## Extended API
-
-The `DMC4000` model supports additional methods that are not part of the standard Viam motor API:
-
-### Home
-
-Run the DMC homing routine.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-**Parameters:**
-
-- None
-
-**Raises:**
-
-- [(error)](https://grpclib.readthedocs.io/en/latest/errors.html#grpclib.exceptions.GRPCError): An error, if one occurred.
-
-For more information on `do_command`, see the [Python SDK Docs](https://python.viam.dev/autoapi/viam/components/component_base/index.html#viam.components.component_base.ComponentBase.do_command).
-
-```python
-my_motor = Motor.from_robot(robot=robot, name='my_motor')
-
-# Home the motor
-home_dict = {
-  "command": "home"
-}
-await my_motor.do_command(home_dict)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-
-**Returns:**
-
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-For more information, see the Go SDK docs on [`Home`](https://pkg.go.dev/go.viam.com/rdk/components/motor/dmc4000#Motor.Home) and on [`DoCommand`](https://pkg.go.dev/go.viam.com/rdk/components/motor/dmc4000#Motor.DoCommand).
-
-```go
-// Home the motor
-resp, err := myMotorComponent.DoCommand(ctx, map[string]interface{}{"command": "home"})
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Jog
-
-Move the motor indefinitely at the specified RPM.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-**Parameters:**
-
-- `rpm` [(float64)](https://pkg.go.dev/builtin#float64): The revolutions per minute at which the motor will turn indefinitely.
-
-**Raises:**
-
-- [(error)](https://grpclib.readthedocs.io/en/latest/errors.html#grpclib.exceptions.GRPCError): An error, if one occurred.
-
-For more information on `do_command`, see the [Python SDK Docs](https://python.viam.dev/autoapi/viam/components/component_base/index.html#viam.components.component_base.ComponentBase.do_command).
-
-```python
-my_motor = Motor.from_robot(robot=robot, name='my_motor')
-
-# Run the motor indefinitely at 70 rpm
-jog_dict = {
-  "command": "jog",
-  "rpm": 70
-}
-await my_motor.do_command(jog_dict)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-- `rpm` [(float64)](https://pkg.go.dev/builtin#float64): The revolutions per minute at which the motor will turn indefinitely.
-
-**Returns:**
-
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-For more information, see the Go SDK Docs on [`Jog`](https://pkg.go.dev/go.viam.com/rdk/components/motor/dmc4000#Motor.Jog) and on [`DoCommand`](https://pkg.go.dev/go.viam.com/rdk/components/motor/dmc4000#Motor.DoCommand).
-
-```go
-// Run the motor indefinitely at 70 rpm
-resp, err := myMotorComponent.DoCommand(ctx, map[string]interface{}{"command": "jog", "rpm": 70})
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Raw
-
-Send [raw string commands](https://www.galil.com/downloads/manuals-and-data-sheets) to the controller.
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-**Parameters:**
-
-- `raw_input` [(String)](https://pkg.go.dev/builtin#string): The raw string to send to the controller.
-
-**Raises:**
-
-- [(error)](https://grpclib.readthedocs.io/en/latest/errors.html#grpclib.exceptions.GRPCError): An error, if one occurred.
-
-For more information on `do_command`, see the [Python SDK Docs](https://python.viam.dev/autoapi/viam/components/component_base/index.html#viam.components.component_base.ComponentBase.do_command).
-
-```python
-my_motor = Motor.from_robot(robot=robot, name='my_motor')
-
-raw_dict = {
-  "command": "raw",
-  "raw_input": "home"
-}
-await my_motor.do_command(raw_dict)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-- `raw_input` [(String)](https://pkg.go.dev/builtin#string): The raw string to send to the controller.
-
-**Returns:**
-
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-For more information, see the Go SDK Docs on [`Raw`](https://pkg.go.dev/go.viam.com/rdk/components/motor/dmc4000#Motor.Raw) and on [`DoCommand`](https://pkg.go.dev/go.viam.com/rdk/components/motor/dmc4000#Motor.DoCommand).
-
-```go
-resp, err := myMotorComponent.DoCommand(ctx, map[string]interface{}{"command": "jog", "raw_input": "home"})
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Test the motor
-
-{{< readfile "/static/include/components/test-control/motor-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/motor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/motor/" customTitle="Motor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/motor/encoded-motor.md b/docs/operate/reference/components/motor/encoded-motor.md
deleted file mode 100644
index 4860a14487..0000000000
--- a/docs/operate/reference/components/motor/encoded-motor.md
+++ /dev/null
@@ -1,205 +0,0 @@
----
-title: "Configure a Motor with an Encoder"
-linkTitle: "Encoded Motors"
-weight: 90
-type: "docs"
-description: "How to configure an encoded motor."
-images: ["/icons/components/motor.svg"]
-aliases:
-  - "/components/motor/gpio/encoded-motor/"
-component_description: "Standard brushed or brushless DC motor with an encoder."
-toc_hide: true
-# SMEs: Rand, James
----
-
-Use an [encoder](/operate/reference/components/encoder/) with a motor to create a closed feedback loop for better control of your machine.
-Instead of sending speed or position commands without a way to verify the motor's behavior, the encoder lets the computer know how the motor is actually rotating in the real world, so adjustments can be made to achieve the desired motor movement.
-
-Some motors come with encoders integrated with or attached to them.
-You can also add an encoder to a motor.
-See the [encoder component documentation](/operate/reference/components/encoder/) for more information on encoders.
-
-Viam supports `gpio` model motors with encoders.
-To configure an encoded motor, you must configure the encoder [per the encoder documentation](/operate/reference/components/encoder/) and then configure a `gpio` motor with an `encoder` attribute in addition to the [standard `gpio` model attributes](/operate/reference/components/motor/gpio/).
-
-Physically connect your motor to a suitable driver chip, and connect that to your board, as well as connecting the encoder.
-Connect the system to power if you want to test it while configuring.
-Configure the [board](/operate/reference/components/board/) and the [encoder](/operate/reference/components/encoder/).
-Then, configure the motor:
-
-<a id="encoder-config">
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Here’s an example configuration:
-
-![An encoded motor config.](/components/motor/encoded-config-ui.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "<your-board-name>",
-      "model": "<your-board-model>",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": []
-    },
-    {
-      "name": "<your-encoder-name>",
-      "model": "<your-encoder-model>",
-      "api": "rdk:component:encoder",
-      "attributes": {
-        ... // insert encoder model specific attributes
-      },
-      "depends_on": []
-    },
-    {
-      "name": "<your-motor-name>",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "board": "<your-board-name>",
-        "pins": {
-          <...> // insert pins struct
-        },
-        "encoder": "<your-encoder-name>",
-        "ticks_per_rotation": <int>,
-        "control_parameters": {
-          "p": <int>,
-          "i": <int>,
-          "d": <int>
-        }
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-Here’s an example configuration:
-
-```json
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "pi",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": []
-    },
-    {
-      "name": "myEncoder",
-      "model": "incremental",
-      "api": "rdk:component:encoder",
-      "attributes": {
-        "board": "local",
-        "pins": {
-          "a": "13",
-          "b": "15"
-        }
-      },
-      "depends_on": []
-    },
-    {
-      "name": "myMotor1",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "board": "local",
-        "pins": {
-          "pwm": "16",
-          "dir": "18"
-        },
-        "encoder": "myEncoder",
-        "ticks_per_rotation": 9600,
-        "control_parameters": {
-          "p": 0.2,
-          "i": 0.5,
-          "d": 0.0
-        }
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-
-{{% tab name="Annotated JSON" %}}
-
-![Same example JSON as on the JSON example tab, with notes alongside it. See attribute table below for all the same information.](/components/motor/motor-encoded-dc-json.png)
-
-{{% /tab %}}
-{{< /tabs >}}
-
-In addition to the [attributes for a non-encoded motor](/operate/reference/components/motor/gpio/), the following attributes are available for encoded DC motors:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `encoder` | string | **Required** | `name` of the encoder. |
-| `ticks_per_rotation` | int | **Required** | Number of ticks in a full rotation of the encoder and motor shaft. |
-| `ramp_rate` | float | Optional | Rate to increase the motor's input voltage (power supply) per second when increasing the speed the motor rotates (RPM). <br> Range = (`0.0`, `1.0`] <br> Default: `0.05` |
-| `control_parameters` | object | Optional | A JSON object containing the coefficients for the proportional, integral, and derivative terms. If you want these values to be auto-tuned, you can set all values to 0: `{ "p": 0, "i": 0, "d": 0 }`, and `viam-server` will auto-tune and log the calculated values. Tuning takes several seconds and spins the motors. Copy the values from the logs and add them to the configuration once tuned for the values to take effect. For more information see [Control motor velocity with encoder feedback](#control-motor-velocity-with-encoder-feedback). |
-
-{{% alert title="Info" color="info" %}}
-
-The attribute [`max_rpm`](/operate/reference/components/motor/gpio/) is not required or available for encoded `gpio` motors.
-
-{{% /alert %}}
-
-{{% alert title="Important" color="note" %}}
-
-If `encoder` is model [`AM5-AS5048`](https://app.viam.com/module/viam/ams),`ticks_per_rotation` must be `1`, as `AM5-AS5048` is an absolute encoder which provides angular measurements directly.
-
-{{% /alert %}}
-
-## Wiring example
-
-Here's an example of an encoded DC motor wired with [the MAX14870 Single Brushed DC Motor Driver Carrier](https://www.pololu.com/product/2961).
-This wiring example corresponds to the [example config above](#encoder-config).
-
-![Example wiring diagram with a Raspberry Pi, brushed DC motor, 12V power supply, and Pololu MAX14870 motor driver. The DIR pin of the driver is wired to pin 18 on the Pi. PWM goes to pin 16. The motor's encoder signal wires (out a and out b) go to pins 11 and 13 on the Pi. The motor's main power wires are connected to the motor driver while its encoder logic power wires are connected to the Pi.](/components/motor/motor-encoded-dc-wiring.png)
-
-## Test the motor
-
-Once your motor is configured and connected, go to the [**CONTROL** tab](/manage/troubleshoot/teleoperate/default-interface/) and click on the motor's dropdown panel.
-Use the buttons to try turning your motor forwards or backwards at different power levels and check whether it moves as expected.
-
-![Motor control panel.](/components/motor/control.png)
-
-For example, a rover with encoded motors following both an [angular](/reference/apis/components/base/#spin) and [linear](/reference/apis/components/base/#movestraight) velocity command:
-
-{{<gif webm_src="/components/encoded-motor/base_moving.webm" mp4_src="/components/encoded-motor/base-moving.mp4" alt="A Viam rover turning in a half circle" max-width="400px" >}}
-
-The position, orientation, and linear and angular velocity of the rover changing as it moves, as measured by a [movement sensor](/operate/reference/components/movement-sensor/):
-
-{{<gif webm_src="/components/encoded-motor/controls_change.webm" mp4_src="/components/encoded-motor/controls_change.mp4" alt="The control tab of a movement sensor on a base with encoded motors as it turns">}}
-
-If the motor does not appear on the **CONTROL** tab, or if you notice unexpected behavior, check your machine's [**LOGS** tab](/manage/troubleshoot/troubleshoot/#check-logs) for errors, and review the configuration.
-
-## Control motor velocity with encoder feedback
-
-{{< readfile "/static/include/components/motor-sensor.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/motor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/motor/" customTitle="Motor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/motor/fake.md b/docs/operate/reference/components/motor/fake.md
deleted file mode 100644
index b75b9eae54..0000000000
--- a/docs/operate/reference/components/motor/fake.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: "Configure a Fake Motor"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake motor to test software without any hardware."
-images: ["/icons/components/motor.svg"]
-aliases:
-  - "/components/motor/fake/"
-component_description: "A model for testing, with no physical hardware."
-toc_hide: true
-# SMEs: Rand, James
----
-
-Configuring a `fake` motor can be convenient for testing software without using any hardware.
-For example, you can use a `fake` component as a placeholder while waiting on a hardware shipment, so that other components that depend on this motor (for example, a [base](/operate/reference/components/base/)) won't fail to initialize, and your control code won't throw errors when it fails to find a physical motor connected to your machine.
-
-{{< tabs name="fake-config">}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `motor` type, then select the `fake` model.
-Enter a name or use the suggested name for your motor and click **Create**.
-
-![A fake motor config.](/components/motor/fake-config-ui.png)
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "<your-motor-name>",
-      "model": "fake",
-      "api": "rdk:component:motor",
-      "attributes": {
-        <...>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "fake-motor",
-      "model": "fake",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "pins": {
-          "dir": "",
-          "pwm": ""
-        },
-        "board": "",
-        "dir_flip": false
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Since a `fake` motor isn't a physical piece of hardware, attributes are only representational and not required.
-However, if you would like to mock up a virtual placeholder for a real, physical motor, you can configure some or all of the following attributes:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | Optional | `name` of the [board](/operate/reference/components/board/) to which the motor driver is wired. |
-| `min_power_pct` | float | Optional | Sets a limit on minimum power percentage sent to the motor. <br> Default: `0.0` |
-| `max_power_pct` | float | Optional | Range is 0.06 to 1.0; sets a limit on maximum power percentage sent to the motor. <br> Default: `1.0` |
-| `pwm_freq` | int | Optional | Sets the PWM pulse frequency in Hz. Many motors operate optimally in the kHz range. <br> Default: `800` |
-| `encoder` | string | Optional | The name of an encoder attached to this motor. See [encoded motor](/operate/reference/components/motor/encoded-motor/). *If an encoder is configured on a `fake` motor, `ticks_per_rotation` becomes required.* |
-| `max_rpm` | float | Optional | An estimate of the max revolutions per minute (RPM) the motor will run at with full power under no load. The [`GoFor`](/reference/apis/components/motor/#gofor) method calculates how much power to send to the motor as a percentage of `max_rpm`. If unknown, you can set it to 100, which will mean that giving 40 as the `rpm` argument to `GoFor` or `GoTo` will set it to 40% speed. *For non-encoded fake motors, this is required or a default is assigned.* <br> Default: `100` |
-| `ticks_per_rotation` | int | Optional* | **Required for calculations if an encoder is configured.* For a stepper motor, the number of steps in one full rotation (200 is common). For an encoded motor, how many encoder ticks in one full rotation. See data sheet (for a real motor). |
-| `dir_flip` | bool | Optional | Flips the direction of "forward" versus "backward" rotation. <br> Default: `false` |
-| `pins` | object | Optional | A struct that holds pin configuration information. |
-
-Nested within `pins`:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `a` | string | Optional | See [Pin Information](#pin-information). Corresponds to "IN1" on many driver data sheets. {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} of the GPIO pin this is wired to on the [board](/operate/reference/components/board/). |
-| `b` | string | Optional | See [Pin Information](#pin-information). Corresponds to "IN2" on many driver data sheets. {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} of the GPIO pin this is wired to on the [board](/operate/reference/components/board/). |
-| `dir` | string | Optional | See [Pin Information](#pin-information). {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} of the GPIO pin this is wired to on the [board](/operate/reference/components/board/). |
-|`pwm` | string | Optional | See [Pin Information](#pin-information). {{< glossary_tooltip term_id="pin-number" text="Pin number" >}} of the GPIO pin this is wired to on the [board](/operate/reference/components/board/). |
-
-## Pin Information
-
-There are three common ways for the computing device to communicate with a brushed DC motor driver chip.
-The driver data sheet (for a real, not fake, motor) will specify which one to use.
-
-- PWM/DIR: One digital input (such as a GPIO pin) sends a [pulse width modulation (PWM)](https://en.wikipedia.org/wiki/Pulse-width_modulation) signal to the driver to control speed while another digital input sends a high or low signal to control the direction.
-- In1/In2 (or A/B): One digital input is set to high and another set to low turns the motor in one direction and vice versa, while speed is controlled with PWM through one or both pins.
-- In1/In2 + PWM: Three pins: an In1 (A) and In2 (B) to control direction and a separate PWM pin to control speed.
-
-## Test the motor
-
-Once your motor is configured and your machine is connected, go to the [**CONTROL** tab](/manage/troubleshoot/teleoperate/default-interface/) and click on the motor's dropdown panel.
-Use the buttons to try turning your motor forwards or backwards at different power levels and notice how the **Position** number changes.
-
-![Motor control panel.](/components/motor/control.png)
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/motor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/motor/" customTitle="Motor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/motor/gpio-micro-rdk.md b/docs/operate/reference/components/motor/gpio-micro-rdk.md
deleted file mode 100644
index 6cf6f64115..0000000000
--- a/docs/operate/reference/components/motor/gpio-micro-rdk.md
+++ /dev/null
@@ -1,170 +0,0 @@
----
-title: "Configure a GPIO Motor (Micro-RDK)"
-linkTitle: "gpio (Micro-RDK)"
-weight: 10
-type: "docs"
-description: "Configure brushed or brushless DC motors with a microcontroller."
-images: ["/icons/components/motor.svg"]
-aliases:
-  - /micro-rdk/motor/gpio/
-  - /components/motor/gpio-micro-rdk/
-micrordk_component: true
-toc_hide: true
-# SMEs: Rand, James
----
-
-The `gpio` model supports [DC motors](https://en.wikipedia.org/wiki/DC_motor) (both brushed and brushless).
-
-You can configure [encoders](/operate/reference/components/encoder/) to work with `gpio` motors.
-Find more information in the [encoded motor documentation](/operate/reference/components/motor/encoded-motor/).
-
-To configure a DC motor as a component of your machine, first make sure the motor is wired to a suitable motor driver, which is in turn wired to the microcontroller.
-Connect the system to power if you want to test it while configuring.
-Configure the [board](/operate/reference/components/board/esp32/) to which the motor driver is wired.
-Then configure the motor:
-Then add your motor:
-
-{{< tabs name="gpio-config">}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `motor` type, then select the `gpio` model.
-Enter a name or use the suggested name for your motor and click **Create**.
-
-![G P I O motor config in the builder UI with the In1 and In2 pins configured and the PWM pin field left blank.](/components/motor/gpio-config-ui.png)
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "<your-board-name>",
-      "model": "<your-board-model>",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": [],
-    },
-    {
-      "name": "<your-motor-name>",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "pins": {
-          "dir": "<int>",
-          "pwm": "<int>"
-        },
-        "board": "<your-board-name>",
-        "min_power_pct": <float>,
-        "max_power_pct": <float>,
-        "pwm_freq": <float>,
-        "dir_flip": <float>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-An example configuration for a `gpio` motor:
-
-```json
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "pi",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": []
-    },
-    {
-      "name": "example-gpio",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "pins": {
-          "dir": "36",
-          "pwm": "32"
-        },
-        "board": "local"
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `gpio` motors:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | **Required** | `name` of the [board](/operate/reference/components/board/) to which the motor driver is wired. |
-| `pins` | object | **Required** | A structure that holds pin configuration information; [see below](#pins). |
-| `min_power_pct` | float | Optional | Sets a limit on minimum power percentage sent to the motor. <br> Default: `0.0` |
-| `max_power_pct` | float | Optional | Range is 0.06 to 1.0; sets a limit on maximum power percentage sent to the motor. <br> Default: `1.0` |
-| `pwm_freq` | int | Optional | Sets the PWM pulse frequency in Hz. Many motors operate optimally in the kHz range. <br> Default: `800` |
-| `dir_flip` | bool | Optional | Flips the direction of "forward" versus "backward" rotation. Default: `false` |
-| `encoder` | string | Optional | The name of an encoder attached to this motor. See [encoded motor](/operate/reference/components/motor/encoded-motor/). |
-
-Refer to your motor and motor driver data sheets for specifics.
-
-## `pins`
-
-There are three common ways for your computer to communicate with a brushed DC motor driver chip.
-**Your motor driver data sheet will specify which one to use.**
-
-- PWM/DIR: Use this if one of your motor driver's pins (labeled "PWM") takes a [pulse width modulation (PWM)](https://en.wikipedia.org/wiki/Pulse-width_modulation) signal to the driver to control speed while another pin labeled "DIR" takes a high or low signal to control the direction.
-  - Configure `pwm` and `dir`.
-- In1/In2: Use this if your motor driver has pins labeled "IN1" and "IN2" or "A" and "B," or similar.
-  One digital signal set to a high voltage and another set to a low voltage turns the motor in one direction and vice versa.
-  Speed is controlled with PWM through one or both pins.
-  - Configure `a` and `b`.
-- In1/In2 and PWM: Use this if your motor driver uses three pins: In1 (A) and In2 (B) to control direction and a separate PWM pin to control speed.
-  - Configure `a`, `b`, and `pwm`.
-
-Inside the `pins` struct you need to configure **two or three** of the following depending on your motor driver:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `a` | string | **Required** for some drivers | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's "IN1" or "A" pin is wired to. |
-| `b` | string | **Required** for some drivers | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's "IN2" or "B" pin is wired to. |
-| `dir` | string | **Required** for some drivers | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's direction ("DIR") pin is wired to. |
-| `pwm` | string | **Required** | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's "PWM" pin is wired to. |
-
-### PWM frequency and `esp32` boards
-
-Each `gpio` motor uses a PWM pin at 10000 Hz PWM frequency.
-
-This leaves you with three remaining PWM frequencies for use on an `esp32`.
-If the frequency of another PWM signal is unimportant, it can also be set to 10000 Hz.
-See [PWM signals on `esp32` pins](/operate/reference/components/board/esp32/#pwm-signals-on-esp32-pins) for more information.
-
-## Test the motor
-
-{{< readfile "/static/include/components/test-control/motor-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/motor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/motor/" customTitle="Motor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/motor/gpio.md b/docs/operate/reference/components/motor/gpio.md
deleted file mode 100644
index 5a09c940aa..0000000000
--- a/docs/operate/reference/components/motor/gpio.md
+++ /dev/null
@@ -1,217 +0,0 @@
----
-title: "Configure a GPIO-Controlled Motor"
-linkTitle: "gpio"
-weight: 10
-type: "docs"
-description: "Configure brushed or brushless DC motors."
-images: ["/icons/components/motor.svg"]
-aliases:
-  - "/components/motor/gpio/"
-no_list: true
-component_description: "Supports standard brushed or brushless DC motors."
-usage: 999999
-toc_hide: true
-# SMEs: Rand, James
----
-
-The `gpio` model supports [DC motors](https://en.wikipedia.org/wiki/DC_motor) (both brushed and brushless).
-
-Technically, you must choose a motor model based on the motor driver, not the motor itself.
-The `gpio` model supports a DC or BLDC motor if it is wired to a motor driver that is controlled by general-purpose input/output (GPIO) pins on a {{< glossary_tooltip term_id="board" text="board" >}} component.
-If your motor driver uses a different communication protocol such as I2C or SPI, you should use a different motor model.
-If you have a stepper motor, use a compatible stepper-specific model such as [`gpiostepper`](/operate/reference/components/motor/gpiostepper/).
-
-{{< alert title="Note" color="note" >}}
-[Encoders](/operate/reference/components/encoder/) can be configured to work with `gpio` motors.
-Find more information in the [encoded motor documentation](/operate/reference/components/motor/encoded-motor/).
-{{< /alert >}}
-
-To configure a DC motor as a component of your machine, first make sure the motor is wired to a suitable motor driver, which is in turn wired to a board.
-Connect the system to power if you want to test it while configuring.
-Configure the [board](/operate/reference/components/board/) to which the motor driver is wired.
-Then configure your motor:
-
-{{< tabs name="gpio-config">}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `motor` type, then select the `gpio` model.
-Enter a name or use the suggested name for your motor and click **Create**.
-
-![G P I O motor config in the builder UI with the In1 and In2 pins configured and the PWM pin field left blank.](/components/motor/gpio-config-ui.png)
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "<your-board-name>",
-      "model": "<your-board-model>",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": [],
-    },
-    {
-      "name": "<your-motor-name>",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "pins": {
-          "dir": "<int>",
-          "pwm": "<int>",
-          "en_low": "<int>"
-        },
-        "board": "<your-board-name>",
-        "max_rpm": <int>,
-        "min_power_pct": <float>,
-        "max_power_pct": <float>,
-        "pwm_freq": <float>,
-        "dir_flip": <float>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-An example configuration for a `gpio` motor:
-
-```json
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "pi",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": []
-    },
-    {
-      "name": "example-gpio",
-      "model": "gpio",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "pins": {
-          "dir": "36",
-          "pwm": "32"
-        },
-        "board": "local",
-        "max_rpm": 500
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Annotated JSON" %}}
-
-![Same example JSON as on the JSON example tab, with notes alongside it. See attribute table below for all the same information.](/components/motor/motor-gpio-json.png)
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `gpio` motors:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `board` | string | **Required** | `name` of the [board](/operate/reference/components/board/) to which the motor driver is wired. |
-| `max_rpm` | int | **Required** | This is an estimate of the maximum RPM the motor will run at with full power under no load. The [`GoFor`](/reference/apis/components/motor/#gofor) method calculates how much power to send to the motor as a percentage of `max_rpm`. If unknown, you can set it to 100, which will mean that giving 40 as the `rpm` argument to `GoFor` or `GoTo` will set it to 40% speed. ***Not required** or available for [encoded](/operate/reference/components/motor/encoded-motor/) `gpio` motors.* |
-| `pins` | object | **Required** | A structure that holds pin configuration information; [see below](#pins). |
-| `min_power_pct` | float | Optional | Sets a limit on minimum power percentage sent to the motor. <br> Default: `0.0` |
-| `max_power_pct` | float | Optional | Range is 0.06 to 1.0; sets a limit on maximum power percentage sent to the motor. <br> Default: `1.0` |
-| `pwm_freq` | int | Optional | Sets the PWM pulse frequency in Hz. Many motors operate optimally in the kHz range. <br> Default: `800` |
-| `dir_flip` | bool | Optional | Flips the direction of "forward" versus "backward" rotation. Default: `false` |
-| `encoder` | string | Optional | The name of an encoder attached to this motor. See [encoded motor](/operate/reference/components/motor/encoded-motor/). |
-
-Refer to your motor and motor driver data sheets for specifics.
-
-## `pins`
-
-There are three common ways for your computer to communicate with a brushed DC motor driver chip.
-**Your motor driver data sheet will specify which one to use.**
-
-- PWM/DIR: Use this if one of your motor driver's pins (labeled "PWM") takes a [pulse width modulation (PWM)](https://en.wikipedia.org/wiki/Pulse-width_modulation) signal to the driver to control speed while another pin labeled "DIR" takes a high or low signal to control the direction.
-  - Configure `pwm` and `dir`.
-- In1/In2: Use this if your motor driver has pins labeled "IN1" and "IN2" or "A" and "B," or similar.
-  One digital signal set to a high voltage and another set to a low voltage turns the motor in one direction and vice versa.
-  Speed is controlled with PWM through one or both pins.
-  - Configure `a` and `b`.
-- In1/In2 and PWM: Use this if your motor driver uses three pins: In1 (A) and In2 (B) to control direction and a separate PWM pin to control speed.
-  - Configure `a`, `b`, and `pwm`.
-
-Inside the `pins` struct you need to configure **two or three** of the following, in addition to `"en_high"` or `"en_low"`, depending on your motor driver:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `a` | string | **Required** for some drivers | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's "IN1" or "A" pin is wired to. |
-| `b` | string | **Required** for some drivers | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's "IN2" or "B" pin is wired to. |
-| `dir` | string | **Required** for some drivers | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's direction ("DIR") pin is wired to. |
-| `pwm` | string | **Required** for some drivers | Board {{< glossary_tooltip term_id="pin-number" text="pin number" >}} this motor driver's "PWM" pin is wired to. |
-| `en_high` / `en_low` | string | Optional | Some drivers have optional enable pins that enable or disable the driver chip. If your chip requires a high signal to be enabled, add `en_high` with the pin number to this struct. If you need a low signal use `en_low`. |
-
-{{% alert title="Important" color="note" %}}
-
-Only two or three of these `pins` attributes are required, depending on your motor driver.
-
-If your motor drivers uses only In1 and In2, and not a third PWM pin, **do not configure a `pwm` pin**.
-
-{{% /alert %}}
-
-## Wiring examples
-
-{{% alert title="Tip" color="tip" %}}
-
-The following are just examples and do not apply to all motor setups.
-Refer to your motor and motor driver data sheets for information on power requirements and how to properly wire your motor.
-
-{{% /alert %}}
-
-### Brushed DC motor
-
-Taking a 12V brushed DC motor controlled by a [DRV8256E Single Brushed DC Motor Driver Carrier](https://www.pololu.com/product/4038) wired to a Raspberry Pi as an example, the wiring diagram would look like this:
-
-![An example wiring diagram showing a Raspberry Pi, 12V power supply, DRV8256E motor driver, and 12V brushed DC motor. The logic side of the driver is connected to the Pi's ground and 3.3V pins. The driver pin for PWM goes to pin 32 on the Pi and the direction pin goes to pin 36 on the Pi. The motor side of the motor driver is connected to the ground and 12V terminals of a power supply and the OUT1 and OUT2 pins go to the two terminals of the motor.](/components/motor/motor-brushed-dc-wiring.png)
-
-The signal wires in the diagram run from two GPIO pins on the Pi to the DIR and PWM pins on the motor driver.
-Refer to a [Raspberry Pi pinout schematic](https://pinout.xyz/) to locate generic GPIO pins and determine their pin numbers for configuration.
-
-### Brushless DC motor
-
-Brushless DC motor drivers work in much the same way as brushed DC motor drivers.
-They typically require a PWM/DIR input or an A/B (In1/In2) and PWM input to set the motor power and direction.
-The key difference between a brushed and brushless motor driver is on the motor output side.
-Brushless motors typically have three power connections (commonly referred to as A, B and C; or sometimes Phase 1, 2 and 3) and 3 sensor connections (commonly referred to as Hall A, Hall B, and Hall C) running between the motor and driver.
-
-The configuration file of a BLDC motor with Viam is the same as that of a brushed motor.
-Only the output side of the driver board is different in that more wires connect the driver to the motor.
-
-![An example wiring diagram showing a Raspberry Pi, 12V power supply, RioRand 400W brushless DC motor controller, and 3 phase 12V brushless DC motor. The motor has three power wires (one for each phase) and five sensor wires (two to power the sensor and one for each of the three Hall effect sensors).](/components/motor/motor-brushless-dc-wiring.png)
-
-## Test the motor
-
-{{< readfile "/static/include/components/test-control/motor-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/motor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/motor/" customTitle="Motor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/motor/gpiostepper.md b/docs/operate/reference/components/motor/gpiostepper.md
deleted file mode 100644
index 8b4b789afc..0000000000
--- a/docs/operate/reference/components/motor/gpiostepper.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: "Configure a GPIO-Controlled Stepper Motor"
-linkTitle: "gpiostepper"
-weight: 20
-type: "docs"
-description: "Configure a bipolar stepper motor with current regulation and 1/32 microstepping driven by a basic driver."
-images: ["/icons/components/motor.svg"]
-aliases:
-  - "/components/motor/gpiostepper/"
-component_description: "Supports stepper motors driven by basic GPIO-controlled stepper driver chips."
-usage: 900000
-toc_hide: true
-# SMEs: Rand, James
----
-
-The `gpiostepper` model of the motor component supports bipolar [stepper motors](https://en.wikipedia.org/wiki/Stepper_motor) controlled by basic stepper driver chips (such as [DRV8825](https://www.ti.com/product/DRV8825), [A4988](https://www.pololu.com/product/1182), or [TMC2209](https://www.trinamic.com/support/eval-kits/details/tmc2209-bob/)) that take step and direction input through GPIO and move the motor one step per pulse.
-
-{{< alert title="Tip" color="tip" >}}
-Viam also supports some more advanced stepper driver chips like the [TMC5072](https://github.com/viam-modules/analog-devices/) that have their own microcontrollers that handle things like speed and acceleration control.
-{{< /alert >}}
-
-To use a `gpiostepper` motor as a component of your machine, first wire your motor to a suitable stepper motor driver, which is in turn wired to a board.
-Configure the [board](/operate/reference/components/board/) to which the motor driver is wired.
-Then configure the motor:
-
-{{< tabs name="gpiostepper-config">}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `motor` type, then select the `gpiostepper` model.
-Enter a name or use the suggested name for your motor and click **Create**.
-
-![Screenshot of a gpiostepper motor config with the step and dir pins configured to pins 13 and 15.](/components/motor/gpiostepper-config-ui.png)
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json
-{
-  "components": [
-    {
-      "name": "<your-board-name>",
-      "model": "<your-board-model>",
-      "api": "rdk:component:board",
-      "attributes": {},
-      "depends_on": [],
-    },
-    {
-      "name": "<your-motor-name>",
-      "model": "gpiostepper",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "board": "<your-board-name>",
-        "pins": {
-          "step": "<pin-number>",
-          "dir": "<pin-number>"
-        },
-        "ticks_per_rotation": <int>,
-        "stepper_delay_usec": <int>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-Here’s an example of a basic stepper driver config:
-
-```json
-{
-  "components": [
-    {
-      "name": "example-board",
-      "model": "pi",
-      "api": "rdk:component:board"
-    },
-    {
-      "name": "example-motor",
-      "model": "gpiostepper",
-      "api": "rdk:component:motor",
-      "attributes": {
-        "board": "example-board",
-        "pins": {
-          "step": "13",
-          "dir": "15"
-        },
-        "ticks_per_rotation": 200
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Annotated JSON" %}}
-
-![motor-gpiostepper-json.](/components/motor/motor-gpiostepper-json.png)
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `gpiostepper` motors:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ---------- |
-| `board` | string | **Required** | `name` of the [board](/operate/reference/components/board/) the motor driver is wired to. |
-| `pins` | object | **Required** |  A struct containing the [board](/operate/reference/components/board/) {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}} that the `step` and `dir` pins of the motor driver are wired to. |
-| `ticks_per_rotation` | int | **Required** | Number of full steps in a rotation. 200 (equivalent to 1.8 degrees per step) is very common. If your data sheet specifies this in terms of degrees per step, divide 360 by that number to get ticks per rotation. |
-| `stepper_delay_usec` | int | Optional | Time in microseconds to remain high for each step. Required when using the SetPower API. |
-
-Refer to your motor and motor driver data sheets for specifics.
-
-## Wiring example
-
-Typically, a stepper motor will have an even number of wires.
-Each pair of wires forms a loop through a coil of the motor.
-In the case of a four wire (bi-polar) stepper, one pair of wires may be labeled A1 and A2 and the other B1 and B2.
-Refer to your motor data sheet and motor driver data sheet for correct wiring.
-
-The following example uses a Big Tree Tech breakout board with a [TMC2209 integrated circuit](https://www.trinamic.com/products/integrated-circuits/details/tmc2209-la/) to drive a two phase stepper motor.
-
-![An example wiring diagram for a four wire Nema 17 stepper motor driven by a Big Tree Tech TMC2209 stepper driver. The driver is connected to a Raspberry Pi with step and dir pins, as well as logic power wires. A separate 12V power supply is attached to the motor driver to power the motor.](/components/motor/motor-gpiostepper-wiring.png)
-
-In this particular example the enable pin on the upper left corner of the driver is connected to ground to pull it low.
-See the data sheet of your stepper motor and stepper motor driver for information on how to wire your specific hardware.
-
-## Test the motor
-
-{{< readfile "/static/include/components/test-control/motor-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/motor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/motor/" customTitle="Motor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/movement-sensor/_index.md b/docs/operate/reference/components/movement-sensor/_index.md
deleted file mode 100644
index 5b7efdc2ff..0000000000
--- a/docs/operate/reference/components/movement-sensor/_index.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: "Movement Sensor Component"
-linkTitle: "Movement Sensor"
-childTitleEndOverwrite: "Movement Sensor"
-weight: 70
-type: "docs"
-description: "A sensor that measures location, kinematic data, or both."
-tags: ["movement sensor", "gps", "imu", "sensor", "components"]
-icon: true
-images: ["/icons/components/imu.svg"]
-no_list: true
-modulescript: true
-hide_children: true
-date: "2024-10-21"
-aliases:
-  - /components/movement-sensor/
-  - /micro-rdk/movement-sensor/
-  - /build/micro-rdk/movement-sensor/
-# SME: Rand
----
-
-The movement sensor component provides an API for GPS location, linear velocity and acceleration, angular velocity and acceleration and heading.
-
-If you have hardware or software that provides such measurements, use a movement sensor component.
-
-## Configuration
-
-To use a movement sensor and get its measurements, you need to add it to your machine's configuration.
-
-Go to your machine's **CONFIGURE** page, and add a model that supports your sensor.
-
-The following list shows the available sensor models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:movement_sensor" type="movement_sensor" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`accel-adxl345`](accel-adxl345-micro-rdk/) | The [Analog Devices ADXL345](https://www.analog.com/en/products/adxl345.html) digital accelerometer |
-| [`gyro-mpu6050`](gyro-mpu6050-micro-rdk/) | A gyroscope/accelerometer manufactured by TDK InvenSense |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [movement sensor API](/reference/apis/components/movement-sensor/) supports the following methods:
-
-Different movement sensors provide different data, so be aware that not all of the methods below are supported by all movement sensors.
-
-{{< alert title="Tip" color="tip" >}}
-You can run `GetProperties` on your sensor for a list of its supported methods.
-{{< /alert >}}
-
-<!-- IMPORTANT: This resource uses a manual table file. Automation does not update this file! -->
-<!-- Please be sure to update this manual file if you are updating movement-sensor! -->
-
-{{< readfile "/static/include/components/apis/movement-sensor.md" >}}
-
-## Troubleshooting
-
-If your movement sensor is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your movement sensor model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the movement sensor there.
-1. Disconnect and reconnect your movement sensor.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
-
-To capture data from the movement sensor or use it for motion, see the following services:
-
-- [data management service](/data/capture-sync/capture-and-sync-data/): to capture and sync the movement sensor's data
-- [motion service](/operate/reference/services/motion/): to move machines or components of machines
-- [navigation service](/operate/reference/services/navigation/): to navigate with GPS
-- [SLAM service](/operate/reference/services/slam/): for mapping
diff --git a/docs/operate/reference/components/movement-sensor/accel-adxl345-micro-rdk.md b/docs/operate/reference/components/movement-sensor/accel-adxl345-micro-rdk.md
deleted file mode 100644
index 8625311b46..0000000000
--- a/docs/operate/reference/components/movement-sensor/accel-adxl345-micro-rdk.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: "Configure an ADXL345 Accelerometer (Micro-RDK)"
-linkTitle: "accel-adxl345 (Micro-RDK)"
-titleMustBeLong: true
-weight: 20
-type: "docs"
-description: "Configure an ADXL345 digital accelerometer with a microcontroller."
-images: ["/icons/components/imu.svg"]
-aliases:
-  - /micro-rdk/movement-sensor/accel-adxl345/
-  - /components/movement-sensor/accel-adxl345-micro-rdk/
-micrordk_component: true
-toc_hide: true
-# SMEs: Rand, Kim Mishra
----
-
-The `accel-adxl345` movement sensor model supports the Analog Devices [ADXL345 digital accelerometer](https://www.analog.com/en/products/adxl345.html).
-This three axis accelerometer supplies linear acceleration data, supporting the `LinearAcceleration` method.
-
-Physically connect your movement sensor to your microcontroller and power both on.
-Then, configure the movement sensor:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `movement-sensor` type, then select the `accel-adxl345` model.
-Enter a name or use the suggested name for your movement sensor and click **Create**.
-
-{{< imgproc src="/components/movement-sensor/adxl345-builder.png" alt="Creation of an `accel-adxl345` movement sensor." resize="600x" class="shadow"  >}}
-
-Copy and paste the following attribute template into your movement sensor's attributes field.
-Then remove and fill in the attributes as applicable to your movement sensor, according to the table below.
-
-{{< tabs >}}
-{{% tab name="Attributes template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "board": "<your-board-name>",
-  "i2c_bus": "<your-i2c-bus-name-on-board>",
-  "use_alt_i2c_address": <boolean>,
-}
-```
-
-{{% /tab %}}
-{{% tab name="Attributes example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "board": "local",
-  "i2c_bus": "default_i2c_bus"
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-sensor-name>",
-      "model": "accel-adxl345",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {
-        "board": "<your-board-name>",
-        "i2c_bus": "<your-i2c-bus-name-on-board>",
-        "use_alt_i2c_address": <boolean>
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "esp32",
-      "api": "rdk:component:board",
-      "attributes": {
-        "pins": [15, 21, 22],
-        "i2cs": [
-          {
-            "name": "default_i2c_bus",
-            "bus": "i2c0",
-            "data_pin": 21,
-            "clock_pin": 22
-          }
-        ]
-      }
-    },
-    {
-      "name": "my-adxl",
-      "model": "accel-adxl345",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {
-        "board": "local",
-        "i2c_bus": "default_i2c_bus",
-        "use_alt_i2c_address": false
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Attributes
-
-<!-- prettier-ignore -->
-| Name | Type   | Required? | Description |
-| ---- | ------ | --------- | ----------- |
-| `board` | string | **Required** | The `name` of the [board](/operate/reference/components/board/) to which the device is wired. |
-| `i2c_bus` | string | **Required** | The `name` of the I<sup>2</sup>C bus on the [board](/operate/reference/components/board/) wired to this device. |
-| `use_alt_i2c_address` | bool | Optional | Depends on whether you wire SDO low (leaving the default address of 0x53) or high (making the address 0x1D). If high, set true. If low, set false or omit the attribute. <br> Default: `false` |
-
-## Test the movement sensor
-
-After you configure your movement sensor, navigate to the [Control tab](/manage/troubleshoot/teleoperate/default-interface/) and select the dedicated movement sensor dropdown panel.
-This panel presents the data collected by the movement sensor.
-
-{{<imgproc src="/components/movement-sensor/movement-sensor-control-tab-adxl345.png" resize="400x" declaredimensions=true alt="The movement sensor component in the control tab">}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/movement-sensor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/movement-sensor/" customTitle="Movement sensor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/movement-sensor/fake.md b/docs/operate/reference/components/movement-sensor/fake.md
deleted file mode 100644
index df727b03f0..0000000000
--- a/docs/operate/reference/components/movement-sensor/fake.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: "Configure a Fake Movement Sensor"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake movement sensor to test software without any hardware."
-images: ["/icons/components/imu.svg"]
-aliases:
-  - "/components/movement-sensor/fake/"
-component_description: "A model for testing, with no physical hardware."
-toc_hide: true
-# SMEs: Rand
----
-
-You can use the `fake` movement sensor model to test movement sensor code without connecting to any actual hardware.
-
-The `fake` model supports all movement sensor methods: `Accuracy`, `AngularVelocity`, `CompassHeading`, `LinearAcceleration`, `LinearVelocity`, `Orientation`, `Position`, `Properties`, and `Readings`.
-Note that this model does not get any actual readings, so it supports these methods by returning placeholder data.
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `movement-sensor` type, then select the `fake` model.
-Enter a name or use the suggested name for your movement sensor and click **Create**.
-
-{{< imgproc src="/components/movement-sensor/fake-builder.png" alt="Creation of an `fake` movement sensor." resize="1200x" style="width:650px" class="shadow"  >}}
-
-Edit and fill in the attributes as applicable.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": <sensor_name>,
-      "model": "fake",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {},
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "myFakeSensor",
-      "model": "fake",
-      "api": "rdk:component:movement_sensor"
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Test the movement sensor
-
-After you configure your movement sensor, navigate to the [Control tab](/manage/troubleshoot/teleoperate/default-interface/) and select the dedicated movement sensor dropdown panel.
-This panel presents the data collected by the movement sensor.
-The sections in the panel include the position, orientation, angular velocity, linear velocity, and linear acceleration.
-
-{{<imgproc src="/components/movement-sensor/movement-sensor-control-tab.png" resize="800x" declaredimensions=true alt="The movement sensor component in the control tab">}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/movement-sensor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/movement-sensor/" customTitle="Movement sensor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/movement-sensor/gyro-mpu6050-micro-rdk.md b/docs/operate/reference/components/movement-sensor/gyro-mpu6050-micro-rdk.md
deleted file mode 100644
index 453d3a6cf2..0000000000
--- a/docs/operate/reference/components/movement-sensor/gyro-mpu6050-micro-rdk.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: "Configure an MPU-6050 (Micro-RDK)"
-linkTitle: "gyro-mpu6050 (Micro-RDK)"
-weight: 40
-type: "docs"
-description: "Configure an MPU-6050 movement sensor with a microcontroller."
-images: ["/icons/components/imu.svg"]
-aliases:
-  - /micro-rdk/movement-sensor/gyro-mpu6050/
-  - /build/micro-rdk/movement-sensor/gyro-mpu6050/
-  - /components/movement-sensor/gyro-mpu6050-micro-rdk/
-micrordk_component: true
-toc_hide: true
-# SMEs: Rand
----
-
-The `gyro-mpu6050` movement sensor model supports a combination [gyroscope and accelerometer manufactured by TDK InvenSense](https://invensense.tdk.com/products/motion-tracking/6-axis/mpu-6050/).
-
-Physically connect your movement sensor to your machine's computer and power both on.
-Then, configure the movement sensor:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `movement-sensor` type, then select the `gyro-mpu6050` model.
-Enter a name or use the suggested name for your movement sensor and click **Create**.
-
-{{< imgproc src="/components/movement-sensor/mpu6050-builder.png" alt="Creation of an `gyro-mpu6050` movement sensor." resize="600x" class="shadow"  >}}
-
-Copy and paste the following attribute template into your movement sensor's attributes field.
-Then remove and fill in the attributes as applicable to your movement sensor, according to the table below.
-
-{{< tabs >}}
-{{% tab name="Attributes template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "board": "<your-board-name>",
-  "i2c_bus": "<your-i2c-bus-name-on-board>",
-  "use_alt_i2c_address": <boolean>
-}
-```
-
-{{% /tab %}}
-{{% tab name="Attributes example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "board": "local",
-  "i2c_bus": "default_i2c_bus"
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-sensor-name>",
-      "model": "gyro-mpu6050",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {
-        "board": "<your-board-name>",
-        "i2c_bus": "<your-i2c-bus-name-on-board>",
-        "use_alt_i2c_address": <boolean>
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "esp32",
-      "api": "rdk:component:board",
-      "attributes": {
-        "pins": [15, 21, 22],
-        "i2cs": [
-          {
-            "name": "default_i2c_bus",
-            "bus": "i2c0",
-            "data_pin": 21,
-            "clock_pin": 22
-          }
-        ]
-      }
-    },
-    {
-      "name": "my_accelgyro",
-      "model": "gyro-mpu6050",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {
-        "board": "local",
-        "i2c_bus": "default_i2c_bus"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Attributes
-
-<!-- prettier-ignore -->
-| Name                  | Type    | Required? | Description |
-| --------------------- | ------- | --------- | ----------- |
-| `board`               | string  | **Required** | The `name` of the [board](/operate/reference/components/board/) to which the device is wired. |
-| `i2c_bus`             | string  | **Required** | The `name` of the I<sup>2</sup>C bus configured on your [board](/operate/reference/components/board/) wired to this device. |
-| `use_alt_i2c_address` | boolean | Optional     | Depends on whether you wire AD0 low (leaving the default address of 0x68) or high (making the address 0x69). If high, set `true`. If low, set `false`. <br> Default: `false` |
-
-## Test the movement sensor
-
-After you configure your movement sensor, navigate to the [Control tab](/manage/troubleshoot/teleoperate/default-interface/) and select the dedicated movement sensor dropdown panel.
-This panel presents the data collected by the movement sensor.
-The sections in the panel include the angular velocity and linear acceleration.
-
-{{<imgproc src="/components/movement-sensor/movement-sensor-control-tab-mpu6050.png" resize="800x" declaredimensions=true alt="The movement sensor component in the control tab">}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/movement-sensor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/movement-sensor/" customTitle="Movement sensor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/movement-sensor/merged.md b/docs/operate/reference/components/movement-sensor/merged.md
deleted file mode 100644
index a429a4b02f..0000000000
--- a/docs/operate/reference/components/movement-sensor/merged.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: "Configure a Merged Movement Sensor"
-linkTitle: "merged"
-weight: 40
-type: "docs"
-description: "Configure a merged movement sensor."
-images: ["/icons/components/imu.svg"]
-aliases:
-  - "/components/movement-sensor/merged/"
-component_description: "A model that allows you to aggregate the API methods supported by multiple sensors into a singular sensor client, effectively merging the models of the individual resources."
-toc_hide: true
-# SMEs: Rand
----
-
-The `merged` movement sensor model is an abstraction that combines data from multiple movement sensors.
-This allows you to aggregate the API methods supported by multiple sensors into a singular sensor client.
-
-This is especially useful if you want to get readings of position and orientation _or_ linear and angular velocity at the same time, which are normally separately supported and returned by [`GPS`](/operate/reference/components/movement-sensor/#configuration) or [`IMU`](/operate/reference/components/movement-sensor/#configuration) models, respectively.
-
-To reduce velocity error when your machine is using the [navigation service](/operate/reference/services/navigation/), aggregate `Position()` from a [`GPS`](/operate/reference/components/movement-sensor/#configuration) and `Orientation()` from an [`IMU`](/operate/reference/components/movement-sensor/#configuration) movement sensor in a `merged` model.
-
-Configure a [navigation service](/operate/reference/services/navigation/) to use your merged sensor to navigate.
-
-Before configuring a `merged` movement sensor, configure each movement sensor you want to merge as an individual component according to its [model's configuration instructions](/operate/reference/components/movement-sensor/#configuration).
-Reference the `name` you configure for each individual component in the `merged` sensor's configuration attributes:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `movement-sensor` type, then select the `merged` model.
-Enter a name or use the suggested name for your movement sensor and click **Create**.
-
-{{< imgproc src="/components/movement-sensor/merged-config-builder.png" alt="Creation of an `merged` movement sensor." resize="1200x" style="width:650px" class="shadow"  >}}
-
-Fill in the attributes as applicable to your movement sensor, according to the table below.
-For example:
-
-{{< imgproc src="/components/movement-sensor/merged-config-builder-attributes.png" alt="Creation of an `merged` movement sensor with attributes filled in." resize="1200x" style="width:650px" >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-sensor-name>",
-      "model": "merged",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {
-        "position": ["<your-gps-sensor-name-1>", "<your-gps-sensor-name-2>"],
-        "orientation": ["<your-imu-sensor-name-1>"],
-        "compass_heading": ["<your-gps-sensor-name-1>"],
-        "angular_velocity": ["<your-imu-sensor-name-1>"],
-        "linear_velocity": ["<your-gps-sensor-name-1>"],
-        "linear_acceleration": ["<your-accelerometer-sensor-name-1>"]
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-// { "components": [ { ... },
-{
-  "name": "<your-sensor-name>",
-  "model": "merged",
-  "api": "rdk:component:movement_sensor",
-  "attributes": {
-    "position": ["gps1"],
-    "orientation": ["imu-wit"],
-    "compass_heading": ["gps1"],
-    "angular_velocity": ["imu-wit", "mpu6050"],
-    "linear_velocity": ["gps1"],
-    "linear_acceleration": ["adxl345"]
-  },
-  "depends_on": []
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Attributes
-
-Configure an array of the `name` of each movement sensor you want to add to your machine as a merged resource in the attributes of the `merged` movement sensor model:
-
-- The name of each attribute represents the `Property` that the particular movement sensor supports, or the type of reading or measurement that it takes.
-- Get the properties supported by each model from its [model configuration documentation](/operate/reference/components/movement-sensor/#configuration), or by calling [`GetProperties()`](/reference/apis/components/movement-sensor/#getproperties) on the sensor.
-- Put the `name` of each movement sensor into the attribute array for the type of reading it supports.
-  You can use the same sensor for multiple attributes if it supports multiple properties.
-
-<!-- prettier-ignore -->
-| Name                  | Type  | Required? | Description |
-| --------------------- | ----- | --------- | ----------- |
-| `position`            | array | **Dependent on Readings Type Supported** | The `name` of the movement sensor you want to merge, if it reads position.                 |
-| `orientation`         | array | **Dependent on Readings Type Supported** | The `name` of the movement sensor you want to merge, if it reads orientation.              |
-| `compass_heading`     | array | **Dependent on Readings Type Supported** | The `name` of the movement sensor you want to merge, if it reads compass heading position. |
-| `linear_velocity`     | array | **Dependent on Readings Type Supported** | The `name` of the movement sensor you want to merge, if it reads linear velocity.          |
-| `angular_velocity`    | array | **Dependent on Readings Type Supported** | The `name` of the movement sensor you want to merge, if it reads angular velocity.         |
-| `linear_acceleration` | array | **Dependent on Readings Type Supported** | The `name` of the movement sensor you want to merge, if it reads linear acceleration       |
-
-Note that only one sensor from each array can be used to retrieve each type of reading.
-Your machine uses the first sensor in the array that has implemented the relevant API method in its model and does not raise an error at runtime.
-For instance, in the **JSON Example** above, if both `"imu-wit"` and `"mpu6050"` support returning `angular_velocity`, `"mpu6050"` is only used to read angular velocity on the machine if `"imu-wit"` returns an error at runtime.
-
-## Test the movement sensor
-
-After you configure your movement sensor, navigate to the [Control tab](/manage/troubleshoot/teleoperate/default-interface/) and select the dedicated movement sensor dropdown panel.
-This panel presents the data collected by the movement sensor.
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/movement-sensor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/movement-sensor/" customTitle="Movement sensor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/movement-sensor/set-up-base-station.md b/docs/operate/reference/components/movement-sensor/set-up-base-station.md
deleted file mode 100644
index dfddfaa695..0000000000
--- a/docs/operate/reference/components/movement-sensor/set-up-base-station.md
+++ /dev/null
@@ -1,217 +0,0 @@
----
-title: "Set up a SparkFun RTK Reference Station"
-linkTitle: "SparkFun RTK Reference Station Setup"
-weight: 20
-type: "docs"
-description: "Follow this guide to set up your own SparkFun RTK base station, a high-precision GPS module designed for use with the RTK satellite navigation technique."
-images: ["/icons/components/imu.svg"]
-no_component: true
-date: "2024-01-01"
-aliases:
-  - /components/movement-sensor/set-up-base-station/
-toc_hide: true
-# updated: ""  # When the content was last entirely checked
-# SMEs: Susmita
----
-
-Follow this guide to set up your [SparkFun RTK Reference Station](https://www.sparkfun.com/products/22429), a high-precision GPS module designed for use with the Real-Time Kinematic (RTK) satellite navigation technique.
-RTK improves the precision of positional data from satellite-based positioning systems like the Global Positioning System (GPS).
-When placed in a known location, the RTK Reference Station calculates and transmits correction data to RTK-enabled GPS receivers based on satellite signals it receives.
-
-After following this guide, you can provide the mount point, username, password, and URL from your reference station's NTRIP server in your Viam machine config for the [`gps-nmea-rtk-pmtk` and `gps-nmea-rtk-serial`](https://github.com/viam-modules/gps/tree/main/rtk) models of movement sensor to allow a rover or other machine configured with your sensor to apply corrections from the reference station, enabling your machine to achieve sub-centimeter-level accuracy in positioning.
-
-## Reserve an RTK2GO casting service
-
-To distribute the correction information from your reference station, you should reserve an RTK2GO casting service for your station.
-
-Follow the instructions on [New Base Station Reservation](http://rtk2go.com/sample-page/new-reservation/) to enter information about your reference station.
-Select **Ntrip Rev1** for **NTRIP Protocol to Use**.
-Wait for the confirmation email, to which you need to reply.
-Upon reply, if you didn't request a specific password you receive a randomized password for your mount point.
-Save the details of your mountpoint password, username (email), mountpoint name and caster URL, as you need it later in this set up process.
-
-For more information about the RTK2GO reservation system, see [Reservations](http://rtk2go.com/reservations/).
-
-## Set up the reference station hardware
-
-Insert the microSD card that comes with the Reference Station kit into the microSD card slot:
-
-![microSD card slot highlighted on reference station.](/components/movement-sensor/sparkfun-microsd.png)
-
-Connect the GNSS Surveying Antenna included with the Reference Station kit to the **UBLOX** connector on the kit, and connect the kit's SMA WiFi / Bluetooth Antenna to the **ESP32** connector on the kit:
-
-![UBLOX and ESP32 connections highlighted on reference station.](/components/movement-sensor/sparkfun-connectors.png)
-
-## Bring the antenna outside
-
-Bring the surveying antenna outside, where it can have a clear 360 degree view of the sky.
-You must do this to enable casting from the reference station.
-
-## Power up the reference station
-
-You can power up the base station in several ways, described in the [RTK Reference Station Hookup Guide](https://learn.sparkfun.com/tutorials/sparkfun-rtk-reference-station-hookup-guide?_ga=2.100337244.338983596.1711988256-2122519039.1685030641#hardware-overview).
-You can choose to power it up using USB-C or Ethernet (PoE):
-
-![Power and PoE ports highlighted on reference station.](/components/movement-sensor/sparkfun-ethernet.png)
-
-## Configure CfgWiFi mode
-
-**CfgWiFi** mode allows you to configure the reference station through WiFi.
-You can also configure it using Ethernet (**Cfg Eth** mode) but for that an Ethernet connection is required, which can be limiting for outdoor setup.
-
-To configure **CfgWiFi** mode, select **CfgWiFi** using the reference kit's **MODE** button.
-Press it once to activate the **MODE** menu.
-Press the button again to step through the available modes.
-Once highlighted, pause on **CfgWiFi** to select this mode.
-
-{{% alert title="Tip" color="tip" %}}
-For more information, see the [RTK Reference Station Hookup Guide](https://learn.sparkfun.com/tutorials/sparkfun-rtk-reference-station-hookup-guide#hardware-overview) from SparkFun.
-{{% /alert %}}
-
-## Use WiFi to configure the reference station
-
-When **CfgWiFi** mode is selected, the reference station broadcasts its own WiFi called “RTK Config”.
-
-{{% alert title="Note" color="note" %}}
-It is highly recommended that you use a hotspot for outdoor usage, such as with rovers.
-If you do use a hotspot, configure the reference station on the hotspot network.
-Also ensure that the hotspot is set to 2.4GHz and not 5GHz because the reference station can not connect to a network over 2.4GHz.
-{{% /alert %}}
-
-Connect your phone or computer to the WiFi network called "RTK Config" and use your web browser (Safari or Internet Explorer are recommended over Chrome) to go to the address `192.168.4.1`, which is the default IP address of the reference station.
-At that address you will see the RTK setup configure page displayed:
-
-{{< imgproc src="/components/movement-sensor/sparkfun-configure-page.png" alt="The SparkFun RTK Setup configure page displayed with dropdown menu rows showing different options for configuration." resize="900x" style="width:450px" class="shadow"  >}}
-
-### Update System configuration
-
-Look on the top of the RTK setup configure page and ensure that the firmware version of the base station is v4.0 or higher:
-
-{{< imgproc src="/components/movement-sensor/sparkfun-rtk-firmware.png" alt="The top of the SparkFun RTK Setup configure page with the RTK Firmware version displayed as v4.0." resize="1000x" style="width:500px" class="shadow"  >}}
-
-This is important since as of April 2024, version 4.0 allows the base station to send [RTCM](https://www.xyht.com/gnsslocation-tech/rtcm/) corrections over WiFi.
-To update the version of the firmware to 4.0, select the **System Configuration** dropdown and follow the steps provided in [Updating Firmware Over-The-Air](https://docs.sparkfun.com/SparkFun_RTK_Firmware/firmware_update/#updating-firmware-over-the-air).
-
-### Update GNSS configuration
-
-Select the **GNSS Configuration** dropdown on the RTK setup configure page.
-Hover over the subsequent **i** button for more information about an option, including default values and limits.
-For each option, select the following:
-
-**Measurement Rate:**
-
-- **In Hz:** 4.00 Hz (default).
-- **Seconds between measurements:**: 0.25.
-
-**Dynamic Model:** Portable (default).
-
-**Min SV Elevation:** 10.
-
-**Min C/N0**: Keep the default value here, **6dBHz** for ZED-F9P.
-
-**Constellations:** Keep the default selections here: **GPS**, **SBAS**, **GLONASS**, **BeiDou**, and **Galileo**.
-
-With these recommended values selected, your GNSS Configuration should look like this:
-
-{{< imgproc src="/components/movement-sensor/sparkfun-GNSS-config.png" alt="Recommended GNSS Configuration." resize="900x" style="width:450px" class="shadow"  >}}
-
-Now click on the **Message Rates** box.
-In the Message Menu enable the following messages:
-
-- GGA
-- GLL
-- GNS
-- GSV
-- RMC
-- VTG
-
-This is necessary for this use case because Viam’s RTK driver uses these messages.
-Your **Message Rates** option should look like this:
-
-{{< imgproc src="/components/movement-sensor/sparkfun-GNSS-message-rates.png" alt="Recommended GNSS Message Rates Configuration." resize="900x" style="width:450px" class="shadow"  >}}
-
-### Update Base configuration
-
-Select the **Base Configuration** dropdown on the RTK setup configure page.
-
-**Survey-In:** Enable the **Survey-In** mode, and configure it as follows:
-
-- **Minimum observation time**: 60 (default).
-- **Required Mean 3D standard deviation (m)**: 5.00 (default).
-
-**Fixed**: You only want the **Fixed** mode if your reference station will be stationary at a permanent location.
-Keep this deselected.
-
-**Enable NTRIP Server:** Enable this option.
-Enter the following credentials:
-
-- **Caster Host:** rtk2go.com
-- **Caster Port:** [insert port from your [RTK2GO reservation](#reserve-an-rtk2go-casting-service) URL]
-- **Caster User:** [insert email from your [RTK2GO reservation](#reserve-an-rtk2go-casting-service)]
-- **Mount Point:** [insert name of mountpoint from your [RTK2GO reservation](#reserve-an-rtk2go-casting-service)]
-- **Mount Point PW:** [insert password from your [RTK2GO reservation](#reserve-an-rtk2go-casting-service)]
-
-For example:
-
-{{< imgproc src="/components/movement-sensor/sparkfun-base-configuration.png" alt="Recommended Base Configuration." resize="900x" style="width:450px" class="shadow"  >}}
-
-### Update WiFi configuration
-
-Select the **WiFi Configuration** dropdown on the RTK setup configure page.
-
-**Networks:** Enter credentials for up to 4 WiFi networks.
-The device tries all networks and uses the best network available.
-
-**Configure Mode:** WiFi.
-
-Your WiFi configuration should look like this, with the examples replaced with your real values:
-
-{{< imgproc src="/components/movement-sensor/sparkfun-wifi-configuration.png" alt="Example WiFi Configuration." resize="1000x" style="width:500px" class="shadow"  >}}
-
-### Update Profile configuration
-
-Select the **Profile Configuration** dropdown on the RTK setup configure page.
-
-Select a profile to assign settings to that profile.
-At reset, your RTK device will use the selected settings profile.
-
-Your **Profile Configuration** should look like this:
-
-{{< imgproc src="/components/movement-sensor/sparkfun-profile-configuration.png" alt="Example Profile Configuration." resize="900x" style="width:450px" class="shadow"  >}}
-
-### Save your configuration changes
-
-Select **Save Configuration** on the RTK setup configure page and wait for your configurations to take effect.
-
-## Start RTK2GO casting
-
-Using the reference kit's **MODE** button, switch the mode back to the default **Base**.
-Press the **MODE** button once to activate the menu.
-Press the button again to step through the available modes.
-Once highlighted, pause on **Base** to select this mode.
-
-Because you configured the base station to be in **Survey-in** mode in the [update Base configuration step](#update-base-configuration), it will take your base station up to six minutes to go into **Xmitting RTCM** mode.
-After a few minutes it goes into **Casting** mode.
-Once you see **Casting** on the mode menu display screen, go to `rtk2go.com:2101` in your browser and find your mount point in the source table.
-
-## Next steps: configure an RTK movement sensor
-
-Open the configuration instructions for your RTK-enabled movement sensor model:
-
-- [`gps-nmea-rtk-pmtk`](https://app.viam.com/module/viam/gps)
-- [`gps-nmea-rtk-serial`](https://app.viam.com/module/viam/gps)
-
-Follow the configuration instructions, providing the values you entered for your NTRIP server [Base configuration](#update-base-configuration) as the equal attributes in your Viam machine config:
-
-- `ntrip_url`: your RTK2GO casting URL, comprised of **Caster Host** and **Caster Port** (like `rtk2go.com:2101`)
-- `ntrip_username`: your **Caster User**, which should be the same email you used for your [RTK2GO reservation](#reserve-an-rtk2go-casting-service)]
-- `ntrip_password`: your **Mount Point PW**
-- `ntrip_mountpoint`: your **Mount Point** name
-
-Configuring your movement sensor with your NTRIP casting server access information allows your machine to receive both GPS signals and correction data and apply corrections, increasing the positioning capacity of the movement sensor to sub-centimeter level accuracy.
-
-## Troubleshooting
-
-If your base station loses the WiFi IP address after set up, then trying to reconfigure it in **ConfigWiFi** mode will not work.
-In this case, you must connect the base station to your network through an Ethernet cable and then select **ConfigEth** mode in [Use WiFi to configure the reference station](#use-wifi-to-configure-the-reference-station).
-Then, during [Update system configuration](#update-system-configuration) use the IP address displayed on the reference station to connect and configure it.
diff --git a/docs/operate/reference/components/movement-sensor/wheeled-odometry.md b/docs/operate/reference/components/movement-sensor/wheeled-odometry.md
deleted file mode 100644
index d44f64e231..0000000000
--- a/docs/operate/reference/components/movement-sensor/wheeled-odometry.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: "Configure a Wheeled Odometry Movement Sensor"
-linkTitle: "wheeled-odometry"
-type: "docs"
-description: "Configure a wheeled odometry movement sensor."
-images: ["/icons/components/imu.svg"]
-tags:
-  [
-    "movement sensor",
-    "components",
-    "encoder",
-    "motor",
-    "base",
-    "wheeled",
-    "odometry",
-  ]
-aliases:
-  - "/components/movement-sensor/wheeled-odometry/"
-component_description: "A model that uses encoders to get an odometry estimate from a wheeled base."
-toc_hide: true
-# SMEs: Rand, Martha
----
-
-Configure a `wheeled-odometry` movement sensor to implement _wheeled odometry_ on your machine.
-
-_Wheeled odometry_ is the estimation of the rate of change of position, orientation, linear velocity, and angular velocity using the dimensions of a base, calculated by measuring the movement of the motors through encoders.
-Because of this method of estimation, you don't have to have a specific piece of movement sensor hardware to implement `wheeled-odometry` on your machine.
-This model uses [encoders](/operate/reference/components/encoder/) from [position reporting motors](/operate/reference/components/motor/) to get an odometry estimate of a wheeled base as it moves.
-
-With a configured `wheeled-odometry` movement sensor, your machine calculates an estimation of the position, orientation, linear velocity, and angular velocity of the wheeled base each time `time_interval_msec` elapses during a [session](/reference/apis/sessions/).
-You can access these readings through the [movement sensor API](/reference/apis/components/movement-sensor/#api).
-For the best accuracy with odometry calculations, it is recommended you configure a time interval of less than `1000` milliseconds.
-
-After configuring a `wheeled-odometry` movement sensor, you can operate your base with Viam's built-in services like the [navigation service](/operate/reference/services/navigation/).
-
-## Set-up requirements
-
-To prepare your machine, attach [encoders](/operate/reference/components/encoder/) to each of the position-reporting motors on your base to measure their rotation.
-
-- Select and configure motors that can report their own position, like [`gpio` motors](/operate/reference/components/motor/gpio/) with [encoders](/operate/reference/components/encoder/#configuration), or the [`odrive` module](https://github.com/viam-modules/odrive).
-  You can access this property of a configured motor through the [motor API's `GetProperties()`](/reference/apis/components/motor/#getproperties).
-- Configure your rover as a [wheeled base component](/operate/reference/components/base/wheeled/).
-  Make sure to configure the base width and circumference, as these measurements as a property of the base are vital for accurate odometry estimations by your movement sensor.
-  This movement sensor accesses these values through the base's `GetProperties()` API method.
-- Then, proceed to [configure](#configuration) a `wheeled-odometry` movement sensor with the name of each of the motor components.
-
-## Configuration
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `movement-sensor` type, then select the `wheeled-odometry` model.
-Enter a name or use the suggested name for your movement sensor and click **Create**.
-
-{{< imgproc src="/components/movement-sensor/wheeled-odometry-builder.png" alt="Creation of an `wheeled-odometry` movement sensor." resize="1200x" style="width:650px" class="shadow"  >}}
-
-Fill in the attributes as applicable to your movement sensor, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-wheeledodometry-movement-sensor-name>",
-      "model": "wheeled-odometry",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {
-        "base": "<your-base-name>",
-        "left_motors": ["<your-base-left-motor-name-1>", "<your-base-left-motor-name-2>"],
-        "right_motors": ["<your-base-right-motor-name-1", "your-base-right-motor-name-2>"],
-        "time-interval-msec": <number>
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "my-wheeled-odometer",
-      "model": "wheeled-odometry",
-      "api": "rdk:component:movement_sensor",
-      "attributes": {
-        "base": "my_wheeled_base",
-        "left_motors": ["leftm1", "leftm2"],
-        "right_motors": ["rightm1", "rightm2"]
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Attributes
-
-The following attributes are available for `wheeled-odometry` movement sensors:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `base` | string | **Required** | The `name` of the [base](/operate/reference/components/base/) to which the encoders making up this movement sensor are wired. |
-| `left_motors` | object | **Required** | A list containing the name of each of the bases' left [position-reporting motors](/operate/reference/components/motor/gpio/). |
-| `right_motors` | object | **Required** | A list containing the name of each of the bases' right [position-reporting motors](/operate/reference/components/motor/gpio/). |
-| `time_interval_msec` | float | Optional | The time in milliseconds between each wheeled odometry calculation.<br>Default: `500.0`</br> |
-
-## Test the movement sensor
-
-After you configure your movement sensor, navigate to the [Control tab](/manage/troubleshoot/teleoperate/default-interface/) and select the dedicated movement sensor dropdown panel.
-This panel presents the data collected by the movement sensor.
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/movement-sensor.md" >}}
-
-## Next steps
-
-For more configuration and usage info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/movement-sensor/" customTitle="Movement sensor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/power-sensor/_index.md b/docs/operate/reference/components/power-sensor/_index.md
deleted file mode 100644
index 87844a85b0..0000000000
--- a/docs/operate/reference/components/power-sensor/_index.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: "Power Sensor Component"
-linkTitle: "Power Sensor"
-childTitleEndOverwrite: "Power Sensor"
-weight: 70
-no_list: true
-type: "docs"
-description: "A device that provides information about a machine's power systems, including voltage, current, and power consumption."
-tags: ["sensor", "components", "power sensor", "ina219", "ina226", "renogy"]
-icon: true
-images: ["/icons/components/power-sensor.svg"]
-modulescript: true
-date: "2024-10-21"
-aliases:
-  - "/components/power-sensor/"
-hide_children: true
-# SME: #team-bucket
----
-
-The power sensor component provides an API for getting measurements of voltage, current, and power consumption.
-
-If you have a physical power sensor, an API endpoint, or anything else that provides such measurements, use a power sensor component.
-
-## Configuration
-
-To use a power sensor and get its measurements, you need to add it to your machine's configuration.
-
-Go to your machine's **CONFIGURE** page, and add a model that supports your sensor.
-
-The following list shows the available sensor models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:power_sensor" type="power_sensor" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [power sensor API](/reference/apis/components/power-sensor/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/power_sensor-table.md" >}}
-
-## Troubleshooting
-
-If your power sensor is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your power sensor model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the power sensor there.
-1. Disconnect and reconnect your power sensor.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
-
-To capture data from the power sensor and sync it in the cloud, see the [data management service](/data/capture-sync/capture-and-sync-data/).
diff --git a/docs/operate/reference/components/power-sensor/fake.md b/docs/operate/reference/components/power-sensor/fake.md
deleted file mode 100644
index f5397b9ca6..0000000000
--- a/docs/operate/reference/components/power-sensor/fake.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: "Configure a Fake Power Sensor"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake power sensor to test software without the physical hardware."
-tags: ["sensor", "power sensor"]
-icon: true
-images: ["/icons/components/sensor.svg"]
-aliases:
-  - "/components/power-sensor/fake/"
-component_description: "A model for testing, with no physical hardware."
-toc_hide: true
-# SME: #team-bucket
----
-
-Configure a `fake` power sensor to test implementing a power sensor component on your machine without any physical hardware:
-
-{{< tabs name="Configure a Fake Power Sensor" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `power_sensor` type, then select the `fake` model.
-Enter a name or use the suggested name for your power sensor and click **Create**.
-
-![Fake power sensor configuration panel. No attributes are configured.](/components/power-sensor/fake-config-builder.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-sensor-name>",
-  "model": "fake",
-  "api": "rdk:component:power_sensor",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for `fake` power sensors.
-
-{{< readfile "/static/include/components/test-control/power-sensor-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/power-sensor.md" >}}
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/power-sensor/" customTitle="Power sensor API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/sensor/_index.md b/docs/operate/reference/components/sensor/_index.md
deleted file mode 100644
index 3d5b11da1d..0000000000
--- a/docs/operate/reference/components/sensor/_index.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: "Sensor Component"
-linkTitle: "Sensor"
-childTitleEndOverwrite: "Sensor Component"
-weight: 70
-no_list: true
-type: "docs"
-description: "A device that sends information about the outside world to the computer controlling a machine."
-tags: ["sensor", "components"]
-icon: true
-images: ["/icons/components/sensor.svg"]
-modulescript: true
-aliases:
-  - "/components/sensor/"
-  - /micro-rdk/sensor/
-  - /build/micro-rdk/sensor/
-date: "2024-10-21"
-hide_children: true
-# SME: #team-bucket
----
-
-The sensor component provides an API for getting measurements.
-
-If you have a physical sensor, an API endpoint, or anything else that provides measurements, use a sensor component.
-
-## Configuration
-
-To use a sensor and get its measurements, you need to add it to your machine's configuration.
-Physical sensors often require a [board component](/operate/reference/components/board/) with a configured analog-to-digital converter (ADC).
-Virtual sensors often function without additional dependencies.
-
-Go to your machine's **CONFIGURE** page, and add a model that supports your sensor.
-
-The following list shows the available sensor models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:sensor" type="sensor" no-intro="true">}}
-
-{{< alert title="Add support for other models" color="tip" >}}
-If none of the existing models fit your use case, you can [create a modular resource](/operate/modules/write-a-driver-module/) to add support for it.
-{{< /alert >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`ultrasonic`](ultrasonic-micro-rdk/) | [HC-SR04](https://www.sparkfun.com/products/15569) ultrasonic sensors |
-| [`bme280`](https://github.com/viam-modules/micrordk-bme280) | I2C Driver for the BME280 sensor |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% expand "Measuring movement or power or working with a motor?" %}}
-
-- If your sensor measures GPS, IMU, position, velocity, or acceleration, use a [movement sensor](/operate/reference/components/movement-sensor/).
-- If your sensor measured voltage, current, or power consumption of connected hardware use a [power sensor](/operate/reference/components/power-sensor/).
-- If your sensor detects speed and direction of rotation of a motor or a joint, use an [encoder](/operate/reference/components/encoder/).
-
-{{% /expand%}}
-
-## API
-
-The [sensor API](/reference/apis/components/sensor/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/sensor-table.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/sensor.md" >}}
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{< /cards >}}
-
-To capture data from the sensor, see the [data management service](/data/capture-sync/capture-and-sync-data/).
diff --git a/docs/operate/reference/components/sensor/fake.md b/docs/operate/reference/components/sensor/fake.md
deleted file mode 100644
index 52ac4a5242..0000000000
--- a/docs/operate/reference/components/sensor/fake.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: "Create a Fake Sensor"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake sensor to use for testing."
-tags: ["sensor", "components"]
-icon: true
-images: ["/icons/components/sensor.svg"]
-aliases:
-  - "/components/sensor/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
-# SME: #team-bucket
----
-
-Configure a `fake` sensor to test implementing a sensor component on your machine without any physical hardware:
-
-{{< tabs name="Configure a Fake Sensor" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component**.
-Select the `sensor` type, then select the `fake` model.
-Enter a name or use the suggested name for your sensor and click **Create**.
-
-![An example configuration for a fake sensor. Attributes are left blank.](/components/sensor/fake-sensor-ui-config.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-sensor-name>",
-  "model": "fake",
-  "api": "rdk:component:sensor",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for `fake` sensors.
-
-{{% alert title="Info" color="info" %}}
-
-A call to [`Readings()`](/reference/apis/components/sensor/#getreadings) on a `fake` sensor always returns readings of `{"a":1, "b":2, "c":3}`.
-
-{{% /alert %}}
-
-## Test the sensor
-
-{{< readfile "/static/include/components/test-control/sensor-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/sensor.md" >}}
-
-## Next steps
-
-Check out the [sensor API](/reference/apis/components/sensor/) or check out one of these guides:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/sensor/" customTitle="Sensor API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/sensor/ultrasonic-micro-rdk.md b/docs/operate/reference/components/sensor/ultrasonic-micro-rdk.md
deleted file mode 100644
index cd75fb2c49..0000000000
--- a/docs/operate/reference/components/sensor/ultrasonic-micro-rdk.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: "Configure an Ultrasonic Sensor (Micro-RDK)"
-linkTitle: "ultrasonic (Micro-RDK)"
-weight: 60
-type: "docs"
-description: "Configure an ultrasonic sensor with a microcontroller."
-tags: ["sensor", "components", "ultrasonic"]
-icon: true
-images: ["/icons/components/sensor.svg"]
-micrordk_component: true
-aliases:
-  - /build/micro-rdk/sensor/ultrasonic/
-  - /components/sensor/ultrasonic-micro-rdk/
-toc_hide: true
-# SME: Andrew Morrow
----
-
-Configure an `ultrasonic` sensor to integrate the [HC-S204](https://www.sparkfun.com/products/15569) ultrasonic distance sensor into your machine.
-Physically connect your sensor to your microcontroller and power both on.
-Then, configure the sensor:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `sensor` type, then select the `ultrasonic` model.
-Enter a name or use the suggested name for your sensor and click **Create**.
-
-![Creation of a ultrasonic sensor.](/build/micro-rdk/ultrasonic/ultrasonic-sensor-ui-config.png)
-
-Edit and fill in the attributes as applicable to your sensor, according to the table below.
-Although `"board"` is marked as required in `viam-server`, it is not required for `viam-micro-server` usage.
-
-{{< tabs >}}
-{{% tab name="Attributes template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "trigger_pin": "<pin-number>",
-  "echo_interrupt_pin": "<pin-number>"
-}
-```
-
-{{% /tab %}}
-{{% tab name="Attributes example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "trigger_pin": "15",
-  "echo_interrupt_pin": "18"
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-ultrasonic-sensor-name>",
-      "model": "ultrasonic",
-      "api": "rdk:component:sensor",
-      "attributes": {
-        "trigger_pin": "<pin-number>",
-        "echo_interrupt_pin": "<pin-number>"
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "my-ultrasonic-sensor",
-      "model": "ultrasonic",
-      "api": "rdk:component:sensor",
-      "attributes": {
-        "trigger_pin": "15",
-        "echo_interrupt_pin": "18"
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% /tabs %}}
-
-The following attributes are available for `ultrasonic` sensors:
-
-<!-- prettier-ignore -->
-| Attribute | Type | Required? | Description |
-| --------- | ---- | --------- | ----------- |
-| `trigger_pin` | string | **Required** | The GPIO number of the [board's](/operate/reference/components/board/) GPIO pin that you have wired to the trigger pin of your ultrasonic sensor. |
-| `echo_interrupt_pin` | string | **Required** | The GPIO number of the board's GPIO pin that you have wired to the echo pin of your ultrasonic sensor. Please note that unlike the RDK ultrasonic sensor, you must not use a named pin associated with a digital interrupt configured on your board: it will not (currently) work. |
-| `timeout_ms`  | int | Optional | Time to wait in milliseconds before initiating a timeout when requesting readings from your ultrasonic sensor. <br> Default: `50` <br> Max: `100` |
-
-## Test the sensor
-
-{{< readfile "/static/include/components/test-control/sensor-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/sensor.md" >}}
-
-## Next steps
-
-Check out the [sensor API](/reference/apis/components/sensor/) or check out one of these guides:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/sensor/" customTitle="Sensor API" noimage="true" %}}
-{{% card link="/data/capture-sync/capture-and-sync-data/" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/servo/_index.md b/docs/operate/reference/components/servo/_index.md
deleted file mode 100644
index 2705e3972e..0000000000
--- a/docs/operate/reference/components/servo/_index.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: "Servo Component"
-linkTitle: "Servo"
-childTitleEndOverwrite: "Servo Component"
-weight: 80
-type: "docs"
-description: "A hobby servo is a special type of small motor whose position you can precisely control."
-tags: ["servo", "components"]
-icon: true
-images: ["/icons/components/servo.svg"]
-no_list: true
-modulescript: true
-aliases:
-  - "/components/servo/"
-  - /micro-rdk/servo/
-  - /build/micro-rdk/servo/
-hide_children: true
-date: "2024-10-21"
-# SME: #team-bucket
----
-
-The servo component provides an API for controlling the angular position of a servo precisely or getting its current status.
-
-If you have a physical ["RC" or "hobby" servo motor](https://learn.adafruit.com/adafruit-motor-selection-guide/rc-servos) with built-in potentiometer position sensors, configure it as a servo component.
-
-If you have an industrial servo motor, configure or [create](/operate/modules/write-a-driver-module/) a [motor component](/operate/reference/components/motor/) that supports your hardware.
-
-## Configuration
-
-To use a hobby servo, you need to add it to your machine's configuration.
-
-Go to your machine's **CONFIGURE** page, and add a model that supports your servo.
-
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:servo" type="servo" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`gpio`](gpio-micro-rdk/) | A hobby servo. |
-
-{{% readfile "/static/include/micro-create-your-own.md" %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [servo API](/reference/apis/components/servo/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/servo-table.md" >}}
-
-## Troubleshooting
-
-If your servo is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your servo model's documentation to ensure you have configured all required attributes.
-1. Check that all wires are securely attached to the correct pins on the board.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the servo there.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/servo/fake.md b/docs/operate/reference/components/servo/fake.md
deleted file mode 100644
index 0f8d673803..0000000000
--- a/docs/operate/reference/components/servo/fake.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: "Configure a Fake Servo"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake servo."
-tags: ["servo", "components"]
-icon: true
-images: ["/icons/components/servo.svg"]
-aliases:
-  - "/components/servo/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
-# SME: Rand
----
-
-Configure a `fake` servo to test implementing a servo component on your machine without any physical hardware:
-
-{{< tabs name="Configure a Fake Servo" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `servo` type, then select the `fake` model.
-Enter a name or use the suggested name for your servo and click **Create**.
-
-{{< imgproc src="/components/servo/fake-servo-ui-config.png" alt="An example configuration for a fake servo." resize="1200x" style="width:650px" class="shadow"  >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-fake-servo-name>",
-  "model": "fake",
-  "api": "rdk:component:servo",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for fake servos.
-See [GitHub](https://github.com/viamrobotics/rdk/blob/main/components/servo/fake/servo.go) for API call return specifications.
-
-{{< readfile "/static/include/components/test-control/servo-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/servo.md" >}}
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/servo/" customTitle="Servo API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/servo/gpio-micro-rdk.md b/docs/operate/reference/components/servo/gpio-micro-rdk.md
deleted file mode 100644
index fd38f07eac..0000000000
--- a/docs/operate/reference/components/servo/gpio-micro-rdk.md
+++ /dev/null
@@ -1,159 +0,0 @@
----
-title: "Configure a GPIO Servo (Micro-RDK)"
-linkTitle: "gpio (Micro-RDK)"
-weight: 90
-type: "docs"
-description: "Configure a gpio hobby servo with a microcontroller."
-tags: ["servo", "components"]
-icon: true
-images: ["/icons/components/servo.svg"]
-aliases:
-  - /micro-rdk/servo/gpio/
-  - /build/micro-rdk/servo/gpio/
-  - /components/servo/gpio-micro-rdk/
-micrordk_component: true
-toc_hide: true
-# SME: Gautham
----
-
-Configure a `gpio` servo to integrate a hobby servo controlled by general-purpose input/output (GPIO) pins into your machine.
-Physically connect your servo to your microcontroller and power both on.
-Then, configure the servo:
-
-{{< tabs name="Configure a gpio Servo" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `servo` type, then select the `gpio` model.
-Enter a name or use the suggested name for your servo and click **Create**.
-
-![An example configuration for a gpio servo.](/components/servo/gpio-servo-ui-config.png)
-
-Copy and paste the following attribute template into your servo's attributes field.
-Then remove and fill in the attributes as applicable to your servo, according to the table below.
-
-{{< tabs >}}
-{{% tab name="Attributes template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "pin": "<your-pin-number>",
-  "board": "<your-board-name>",
-  "frequency_hz": <int>,
-  "min_angle_deg": <int>,
-  "max_angle_deg": <int>,
-  "min_period_us": <int>,
-  "max_period_us": <int>,
-  "pwm_resolution": <int>
-}
-```
-
-{{% /tab %}}
-{{% tab name="Attributes example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "pin": "16",
-  "board": "local"
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-servo-name>",
-      "model": "gpio",
-      "api": "rdk:component:servo",
-      "attributes": {
-        "pin": "<your-pin-number>",
-        "board": "<your-board-name>",
-        "frequency_hz": <int>,
-        "min_angle_deg": <int>,
-        "max_angle_deg": <int>,
-        "min_period_us": <int>,
-        "max_period_us": <int>,
-        "pwm_resolution": <int>
-      }
-    }
-  }
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "esp32",
-      "api": "rdk:component:board",
-      "attributes": {
-        "pins": [16]
-      }
-    },
-    {
-      "name": "my_servo",
-      "model": "gpio",
-      "api": "rdk:component:servo",
-      "attributes": {
-        "pin": "16",
-        "board": "local"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `gpio` servos:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `pin` | string | **Required** | The GPIO number of the pin the servo's control wire is wired to on the board. |
-| `board` | string | **Required** | `name` of the [board](/operate/reference/components/board/) the servo is wired to. |
-| `frequency_hz` | int | Optional | The frequency of [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) pulses sent to the servo, in Hertz (*Hz*). <br> Default = [`300`] <br> Range = [`0`, `450`] |
-| `min_angle_deg` | int | Optional | The minimum angle in degrees that the servo can reach. <br> Default = `0` <br> Range = [`0`, `180`] |
-| `max_angle_deg` | int | Optional | The maximum angle in degrees that the servo can reach. <br> Default = `180` <br> Range = [`0`, `180`] |
-| `min_period_us` | int | Optional | Override the safe minimum [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) pulse width in microseconds. <br> Default: `500` |
-| `max_period_us` | int | Optional | Override the safe maximum [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) pulse width in microseconds. <br> Default: `2500` |
-| `pwm_resolution` | int | Optional | The resolution of the [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) driver (for example, the number of ticks for a full period). <br> Default: `0` |
-
-## PWM frequency and `esp32` boards
-
-A `gpio` servo using a PWM pin leaves you with three remaining PWM frequencies for use on an `esp32`.
-If the frequency of another PWM signal is unimportant, it can also be set to the same frequency as your servo.
-See [PWM signals on `esp32` pins](/operate/reference/components/board/esp32/#pwm-signals-on-esp32-pins) for more information.
-
-{{% alert title="Tip" color="tip" %}}
-
-Refer to your servo's data sheet for [pulse-width modulation (PWM)](https://docs.arduino.cc/learn/microcontrollers/analog-output), rotation, and wiring specifications.
-
-{{% /alert %}}
-
-{{< readfile "/static/include/components/test-control/servo-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/servo.md" >}}
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/servo/" customTitle="Servo API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/servo/gpio.md b/docs/operate/reference/components/servo/gpio.md
deleted file mode 100644
index a8024f4f57..0000000000
--- a/docs/operate/reference/components/servo/gpio.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: "Configure a GPIO-Controlled Servo"
-linkTitle: "gpio"
-weight: 90
-type: "docs"
-description: "Configure a gpio servo."
-tags: ["servo", "components"]
-icon: true
-images: ["/icons/components/servo.svg"]
-aliases:
-  - "/components/servo/gpio/"
-component_description: "Supports a hobby servo wired to a board that supports PWM, for example Raspberry Pi 5, Orange Pi, Jetson, or PCAXXXX."
-toc_hide: true
-# SME: Rand
----
-
-Configure a `gpio` servo to integrate a hobby servo controlled by general-purpose input/output (GPIO) pins on a non-`viam:raspberry-pi:rpi` model [board](/operate/reference/components/board/) into your machine.
-Physically connect your servo to your board and power both on.
-Then, configure the servo:
-
-{{< tabs name="Configure a gpio Servo" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `servo` type, then select the `gpio` model.
-Enter a name or use the suggested name for your servo and click **Create**.
-
-{{< imgproc src="/components/servo/gpio-servo-ui-config.png" alt="An example configuration for a gpio servo." resize="1200x" style="width:650px" class="shadow"  >}}
-
-Fill in the attributes as applicable to your servo, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-servo-name>",
-      "model": "gpio",
-      "api": "rdk:component:servo",
-      "attributes": {
-        "pin": "<your-pin-number>",
-        "board": "<your-board-name>",
-        "min_angle_deg": <float>,
-        "max_angle_deg": <float>,
-        "starting_position_deg": <float>,
-        "frequency_hz": <int>,
-        "pwm_resolution": <int>,
-        "min_width_us": <int>,
-        "max_width_us": <int>
-      }
-    }
-  }
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "local",
-      "model": "jetson",
-      "api": "rdk:component:board"
-    },
-    {
-      "name": "my_servo",
-      "model": "gpio",
-      "api": "rdk:component:servo",
-      "attributes": {
-        "pin": "16",
-        "board": "local"
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-The following attributes are available for `gpio` servos:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `pin` | string | **Required** | The {{< glossary_tooltip term_id="pin-number" text="pin number" >}} of the pin the servo's control wire is wired to on the [board](/operate/reference/components/board/). |
-| `board` | string | **Required** | `name` of the [board](/operate/reference/components/board/) the servo is wired to. |
-| `min_angle_deg` | float | Optional | The minimum angle in degrees that the servo can reach. <br> Default = `0.0` <br> Range = [`0.0`, `180.0`] |
-| `max_angle_deg` | float | Optional | The maximum angle in degrees that the servo can reach. <br> Default = `180.0` <br> Range = [`0.0`, `180.0`] |
-| `starting_position_deg` | float | Optional | Starting position of the servo in degrees. <br> Default = `0.0` <br> Range = [`0.0`, `180.0`] |
-| `frequency_hz` | int | Optional | The frequency of [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) pulses sent to the servo, in Hertz (*Hz*). <br> Default = [`300`] <br> Range = [`0`, `450`] |
-| `pwm_resolution` | int | Optional | The resolution of the [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) driver (for example, the number of ticks for a full period). If not specified or given as `0`, the driver will attempt to estimate the resolution. |
-| `min_width_us` | int | Optional | Override the safe minimum [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) pulse width in microseconds. <br> Range > `450` |
-| `max_width_us` | int | Optional | Override the safe maximum [PWM](https://docs.arduino.cc/learn/microcontrollers/analog-output) pulse width in microseconds. <br> Range < `2500` |
-
-{{% alert title="Tip" color="tip" %}}
-
-Refer to your servo's data sheet for [pulse-width modulation (PWM)](https://docs.arduino.cc/learn/microcontrollers/analog-output), rotation, and wiring specifications.
-
-{{% /alert %}}
-
-{{< readfile "/static/include/components/test-control/servo-control.md" >}}
-
-## Troubleshooting
-
-{{< readfile "/static/include/components/troubleshoot/servo.md" >}}
-
-## Next steps
-
-For general configuration and development info, see:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/servo/" customTitle="Servo API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/switch/_index.md b/docs/operate/reference/components/switch/_index.md
deleted file mode 100644
index 0fc2b15728..0000000000
--- a/docs/operate/reference/components/switch/_index.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: "Switch Component"
-linkTitle: "Switch"
-childTitleEndOverwrite: "Switch Component"
-weight: 100
-type: "docs"
-description: "A physical multi-position switch on a machine."
-tags: ["switch", "components"]
-icon: true # this should be used when the image is an icon, it will adjust the sizing and object-fit
-images: ["/icons/components/switch.svg"]
-no_list: true
-modulescript: true
-hide_children: true
-date: "2025-02-20"
-# SMEs:
----
-
-The switch component provides an API for reading the state of a physical switch on a machine that has multiple discrete positions.
-A simple switch has two positions, and a knob could have any number of positions.
-
-## Configuration
-
-To use your switch, you need to add it to your machine's configuration.
-Go to your machine's **CONFIGURE** page, and add a model that supports your switch.
-
-The following list shows the available switch models.
-For configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:component:switch" type="component" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [switch API](/reference/apis/components/switch/) supports the following methods:
-
-{{< readfile "/static/include/components/apis/generated/switch-table.md" >}}
-
-## Troubleshooting
-
-If your switch is not working as expected, follow these steps:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-1. Review your switch model's documentation to ensure you have configured all required attributes.
-1. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the switch there.
-1. Disconnect and reconnect your switch.
-
-If none of these steps work, reach out to us on the [Community Discord](https://discord.gg/viam) and we will be happy to help.
-
-## Next steps
-
-For general configuration, development, and usage info, see:
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{% card link="/operate/control/web-app/" noimage="true" %}}
-{{% card link="/tutorials/services/plan-motion-with-arm-gripper" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/components/switch/fake.md b/docs/operate/reference/components/switch/fake.md
deleted file mode 100644
index 377e209886..0000000000
--- a/docs/operate/reference/components/switch/fake.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: "Configure a Fake Switch"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake switch for testing."
-images: ["/icons/components/switch.svg"]
-tags: ["switch", "components"]
-aliases:
-  - "/components/switch/fake/"
-component_description: "A model used for testing, with no physical hardware."
-toc_hide: true
----
-
-The `fake` switch model is a model for testing switch functionality without physical hardware.
-It simulates a multi-position switch which you can control programmatically.
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `switch` type, then select the `fake` model.
-Enter a name or use the suggested name for your arm and click **Create**.
-
-Fill in the attributes as applicable to your switch, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your-switch-name>",
-      "model": "fake",
-      "type": "switch",
-      "namespace": "rdk",
-      "attributes": {
-        "position_count": <number>,
-        "labels": ["<label1>", "<label2>", "<label3>"]
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "my_switch",
-      "model": "fake",
-      "type": "switch",
-      "namespace": "rdk",
-      "attributes": {
-        "position_count": 4,
-        "labels": ["Off", "Low", "Medium", "High"]
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Attributes
-
-The following attributes are available for the `fake` switch model:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `position_count` | int | **Required** | The number of positions that the switch can be in. Default: `2` |
-| `labels` | array | Optional | An array of labels corresponding to the positions. Default: numeric values for the number of positions, starting with 0. |
-
-## Test the switch
-
-{{< readfile "/static/include/components/test-control/switch-control.md" >}}
-
-## Troubleshooting
-
-If your fake switch is not working as expected:
-
-1. Check your machine logs on the **LOGS** tab to check for errors.
-2. Make sure the `position_count` matches the number of `labels` if both are specified.
-3. Verify that position values used with `SetPosition` are within the valid range (0 to `position_count - 1`).
-4. Click on the **TEST** panel on the **CONFIGURE** or **CONTROL** tab and test if you can use the switch there.
-
-## Next steps
-
-Check out the [switch API](/reference/apis/components/switch/) or check out one of these guides:
-
-{{< cards >}}
-{{% card link="/reference/apis/components/switch/" customTitle="Switch API" noimage="true" %}}
-{{% card link="/operate/modules/configure-modules/" noimage="true" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/controls-package.md b/docs/operate/reference/controls-package.md
deleted file mode 100644
index abced93c62..0000000000
--- a/docs/operate/reference/controls-package.md
+++ /dev/null
@@ -1,667 +0,0 @@
----
-title: "Control package"
-linkTitle: "Control package"
-weight: 60
-type: "docs"
-description: "The Control Package implements feedback control on an endpoint."
-# SME: Nicolas Menard, Rand, Martha
-date: "2022-01-01"
-no_list: true
-aliases:
-  - /internals/controls-package/
-# updated: ""  # When the content was last entirely checked
----
-
-[Encoded motors](/operate/reference/components/motor/encoded-motor/) and [sensor controlled bases](/operate/reference/components/base/sensor-controlled/) use a control loop that is implemented by `viam-server`.
-You can configure the `control_parameters` attribute for both components to adjust the control loop.
-However, if you want to change or customize the control loops on these components beyond the configurable parameter, or you want to add a control loop to a different component, you can use the controls package to [build your own PID control loop](/operate/reference/controls-package/#creating-and-using-a-pid-control-loop).
-
-The control package implements feedback control on an endpoint, which is usually the hardware you are trying to control.
-With the control package, users can design a control loop that monitors a process variable (PV) and compares it with a set point (SP).
-The control package will generate a control action to reduce the error value between the SP and PV (_SP-PV_) to zero.
-
-Control loops are usually represented in a diagrammatic style known as a block diagram.
-Each block represents a transfer function of a component.
-In this representation, the control loop is broken down into successive "blocks".
-
-## Creating and Using a PID Control Loop
-
-A PID control loop is a commonly used method of controls.
-A PID control loop computes a correction for the error value between SP and PV using three terms:
-
-- A _proportional_ term that is the current error
-- An _integral_ term that is the total cumulative error
-- A _derivative_ term that is the rate of change of the error
-
-By tuning the coefficients on each of these terms, you can adjust how your base converges towards the target value, how quickly the system reaches the target value, and how much the system overshoots when approaching the target value.
-
-The following functions are available for creating and using a control loop:
-
-<!-- prettier-ignore -->
-| Method Name | Description |
-| ----------- | ----------- |
-| [`SetupPIDControlConfig`](/operate/reference/controls-package/#setuppidcontrolconfig) | Creates a [PIDLoop](/operate/reference/controls-package/#pidloop) object that contains all the necessary attributes to run a control loop based on the specified [Options](/operate/reference/controls-package/#options). |
-| [`TunePIDLoop`](/operate/reference/controls-package/#tunepidloop) | Automatically tunes the system and logs the calculated PID values for the loop. |
-| [`StartControlLoop`](/operate/reference/controls-package/#startcontrolloop) | Starts the control loop in a background thread. |
-| [`CreateConstantBlock`](/operate/reference/controls-package/#createconstantblock) | Creates a control block of type `constant`, all control loops need at least one constant block representing the set point. |
-| [`UpdateConstantBlock`](/operate/reference/controls-package/#updateconstantblock) | Updates the value of a constant block to the new set point. |
-| [`CreateTrapzBlock`](/operate/reference/controls-package/#createtrapzblock) | Creates a control block of type `trapezoidalVelocityProfile`. Control loops that control position (for example, control loops for encoded motors), need a trapezoidal velocity profile block. |
-| [`UpdateTrapzBlock`](/operate/reference/controls-package/#updatetrapzblock) | Updates the attributes of a trapezoidal velocity profile block to the new desired max velocity. |
-
-### SetupPIDControlConfig
-
-Creates a [PIDLoop](/operate/reference/controls-package/#pidloop) object, which contains all the attributes related to a control loop that a controlled component needs, including, most importantly, the control config.
-
-**Parameters:**
-
-- `pidVals` [([]PIDConfig)](/operate/reference/controls-package/#pidconfig): The P, I, and D values for the control loop, if all are zero the loop will auto-tune and log the calculated PID values.
-- `componentName` [(string)](https://pkg.go.dev/builtin#string): The name of the component that the PID loop controls.
-- `options` [(Options)](/operate/reference/controls-package/#options): All the desired optional parameters to customize the control loop.
-- `c` [(Controllable)](/operate/reference/controls-package/#controllable): An interface that contains the necessary functions to move the controlled component.
-- `logger` (Logger): The logger of the controlled component to log any issues with the control loop setup.
-
-**Returns:**
-
-- [(PIDLoop)](/operate/reference/controls-package/#pidloop): A struct containing all relevant control loop attributes.
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-```go
-pidVals := []control.PIDConfig{{
-  Type: "",
-  P: 1.0,
-  I: 2.0,
-  D: 0.0,
-}}
-
-options := control.Options{
-  PositionControlUsingTrapz: true,
-  LoopFrequency:             100.0,
-}
-
-pidLoop, err := control.SetupPIDControlLoop(pidVals, "motor_name", options, motor, motor.logger)
-```
-
-### TunePIDLoop
-
-Tunes the provided loop to determine the best PID values.
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-- `cancelFunc` [(CancelFunc)](https://pkg.go.dev/context#CancelFunc): A CancelFunc tells an operation to abandon its work.
-
-**Returns:**
-
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-```go
-// add necessary attributes to the PIDLoop struct
-pidLoop := &control.PIDLoop{}
-
-cancelCtx, cancelFunc := context.WithCancel(context.Background())
-err := pidLoop.TunePIDLoop(cancelCtx, cancelFunc)
-```
-
-### StartControlLoop
-
-Starts running the PID control loop to monitor and adjust the inputs to the controlled component.
-
-**Parameters:**
-
-- None
-
-**Returns:**
-
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-```go
-// add necessary attributes to the PIDLoop struct
-pidLoop := &control.PIDLoop{}
-
-err := pidLoop.StartControlLoop()
-```
-
-### CreateConstantBlock
-
-Creates a new control block of type `constant`.
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-- `name` [(string)](https://pkg.go.dev/builtin#string): The desired name of the constant block.
-- `constVal` [(float64)](https://pkg.go.dev/builtin#float64): The value of the new set point.
-
-**Returns:**
-
-[(BlockConfig)](/operate/reference/controls-package/#blockconfig): The config for the newly created block.
-
-```go
-constBlock := control.CreatConstantBlock(context.Background(), "set_point", 10.0)
-```
-
-### UpdateConstantBlock
-
-Creates a new control block of type `constant`, and then updates the control loop to use this new block.
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-- `name` [(string)](https://pkg.go.dev/builtin#string): The name of the constant block.
-- `constVal` [(float64)](https://pkg.go.dev/builtin#float64): The value of the new set point.
-- `loop` (`*Loop`): The control loop to be updated with the newly created constant block.
-
-**Returns:**
-
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-```go
-err := control.UpdateConstantBlock(context.Background(), "set_point", 10.0, loop)
-```
-
-### CreateTrapzBlock
-
-Creates a new control block of type `trapezoidalVelocityProfile`.
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-- `name` [(string)](https://pkg.go.dev/builtin#string): The name of the trapezoidal block.
-- `maxVel` [(float64)](https://pkg.go.dev/builtin#float64): The max velocity for the controlled component to move at.
-- `dependsOn` [([]string)](https://pkg.go.dev/builtin#string): An array of strings containing the names of the other control blocks that the new trapezoidal block depends on. Usually the set point and the end point.
-
-**Returns:**
-
-[(BlockConfig)](/operate/reference/controls-package/#blockconfig): The config for the newly created block.
-
-```go
-trapzBlock := control.CreateTrapzBlock(context.Background(), "set_point", 10.0, []string{"set_point", "endpoint"})
-```
-
-### UpdateTrapzBlock
-
-Creates a new control block of type `trapezoidalVelocityProfile`, and then updates the control loop to use this new block.
-
-**Parameters:**
-
-- `ctx` [(Context)](https://pkg.go.dev/context): A Context carries a deadline, a cancellation signal, and other values across API boundaries.
-- `name` [(string)](https://pkg.go.dev/builtin#string): The name of the trapezoidal block.
-- `maxVel` [(float64)](https://pkg.go.dev/builtin#float64): The max velocity for the controlled component to move at.
-- `dependsOn` [([]string)](https://pkg.go.dev/builtin#string): An array of strings containing the names of the other control blocks that the new trapezoidal block depends on. Usually the set point and the end point.
-- `loop` (`*Loop`): The control loop to be updated with the newly created trapezoidal block.
-
-**Returns:**
-
-- [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
-
-```go
-err := control.UpdateTrapzBlock(context.Background(), "set_point", 10.0, []string{"set_point", "endpoint"}, loop)
-```
-
-### PIDLoop
-
-`PIDLoop` is a struct containing all the attributes for setting up a PID control loop. [`SetupPIDControlConfig`](/operate/reference/controls-package/#setuppidcontrolconfig) will create this object for you.
-
-```go
-type PIDLoop struct {
-  BlockNames   map[string][]string
-  PIDVals      []PIDConfig
-  ControlConf  Config
-  ControlLoop  *Loop
-  Options      Options
-  Controllable Controllable
-}
-```
-
-### PIDConfig
-
-`PIDConfig` is a struct containing the PID values for a control loop. With 2-dimensional control loops (such as a `sensor-controlled` base which controls both linear and angular velocity), the `"type"` type field is required and must be either `"linear_velocity"` or `"angular_velocity"`. For 1-dimensional control loops (such as an encoded motor), the `"type"` field is not necessary.
-
-```go
-type PIDConfig struct {
-  Type string
-  P    float64
-  I    float64
-  D    float64
-}
-```
-
-### Controllable
-
-`Controllable` is an interface that contains the two functions that any component needs to be controlled by a control loop. For any components other than an encoded motor and a sensor controlled base, these functions must be implemented on the component.
-
-- `State()` gets the current state of the endpoint (controlled component) and passes that information on to the next iteration of the control loop
-- `SetState()` takes the information from the latest iteration of the control loop and sets the state of the endpoint (controlled component) to the calculated value.
-
-For example, in an encoded motor, `State()` measures the current position of the motor, so that the next iteration of the control loop knows how far it is from the goal position, or how much error remains. Then the control loop calculates what the next power percentage should be in order to get the motor to its goal position and velocity, and `SetState()` sets that power on the motor.
-
-```go
-type Controllable interface {
-  SetState(ctx context.Context, state []*Signal) error
-  State(ctx context.Context) ([]float64, error)
-}
-```
-
-### Options
-
-`Options` is a struct that contains all of the optional parameters that you can use to customize a control loop during the setup. Since they are all optional, the only options you must set are those that you wish to change from the default.
-
-<!-- prettier-ignore -->
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| `PositionControlUsingTrapz` | bool | Adds a trapezoidalVelocityProfile block to the control config to allow for position control of a component. <br> Default: false |
-| `SensorFeedback2DVelocityControl` | bool | Adds linear and angular blocks to a control config in order to use the sensorcontrolled base component for velocity control. <br> Default: false |
-| `DerivativeType` | string | The type of derivative to be used for the derivative block of a control config. <br> Default: `"backward1st1"` |
-| `UseCustomConfig` | bool | Use this if the necessary config cannot be created using the control loop setup functions. <br> Default: false |
-| `CompleteCustomConfig` | control.Config | The custom control config to be used instead of the config created by the control loop setup functions. <br> Default: control.Config{} |
-| `NeedsAutoTuning` | bool | True when the loop needs to be auto-tuned. This will be set to true automatically if all PID values are 0. <br> Default: false |
-| `LoopFrequency` | float64 | The frequency at which the control loop should run. <br> Default: 50 Hz |
-| `ControllableType` | string | The type of component the control loop will be set up for, currently a base or motor. <br> Default: `"motor_name"` |
-
-```go
-type Options struct {
-  PositionControlUsingTrapz bool
-  SensorFeedback2DVelocityControl bool
-  DerivativeType string
-  UseCustomConfig bool
-  CompleteCustomConfig Config
-  NeedsAutoTuning bool
-  LoopFrequency float64
-  ControllableType string
-}
-```
-
-The built in control loop setup is only structured to work with an encoded motor or a sensor controlled base. If you wish to use a different setup, you can use the options by setting `UseCustomConfig` to `true` and `CompleteCustomConfig` to your custom control loop config of type `control.Config`.
-The [Control Blocks](/operate/reference/controls-package/#control-blocks) section details the different options for control blocks and how to create a `control.Config`.
-
-### BlockConfig
-
-`BlockConfig` is a struct for the configuration of an individual control block.
-You have to build individual BlockConfigs if you use the `UseCustomConfig` option.
-Each block type requires different attributes, which are outlined in the [Control Blocks](/operate/reference/controls-package/#control-blocks) section.
-
-```go
-type BlockConfig struct {
-  Name      string
-  Type      controlBlockType
-  Attribute utils.AttributeMap
-  DependsOn []string
-}
-```
-
-## Control Blocks
-
-The following example is a block diagram of a control loop defined to control the speed of a motor.
-The motor has an encoder that reports the position of the motor.
-
-Measuring the reported position and deriving it to get the speed introduces some error, so you may apply a filter to remove the noise.
-
-Then, calculate the error (_SP-PV_) (in this particular case PV is the speed of the motor) and feed it into your PID.
-
-The PID controller applies a correction to a control function, and outputs the result of this correction to the endpoint block.
-
-An important attribute of the control loop is the frequency at which it runs.
-The higher the frequency, the better the control.
-With more frequent steps the resulting error is smaller, which translates into smaller corrections at each step of the control loop.
-
-```asciidoc
-
-+-------------+            +------------+              +----------+        +----------+
-|             |            |            |              |          |        |          |
-|   SetPoint  +----------->|   Sum      +------------->|  PID     +------->| Endpoint |
-|             |            |            |              |          |        |          |
-|             |            |            |              |          |        |          |
-+-------------+            +------------+              +----------+        +-----+----+
-                                 ^                                               |
-                                 |                                               |
-                           +-----+------+              +----------+              |
-                           |            |              |          |              |
-                           |  Filter    |<-------------+ Derive   |<-------------+
-                           |            |              |          |
-                           |            |              |          |
-                           +------------+              +----------+
-
-```
-
-```json
-"control_config": {
-          "frequency": 100,
-          "blocks": [
-            {
-              "name": "set_point",
-              "type": "constant",
-              ....
-            },
-            {
-              "name": "endpoint",
-              "type": "endpoint",
-              ...
-              "depends_on":["PID"]
-            },
-            {
-              "name" : "Filter",
-              "type": "filter",
-              ...
-              },
-              "depends_on":["Derivative"]
-            },
-            {
-              "name": "Derivative",
-              "type": "derivative",
-              ....
-              "depends_on":["endpoint"]
-            },
-            {
-              "name": "PID",
-              "type": "PID",
-              ...
-              "depends_on":["Sum"]
-            },
-            {
-              "name": "Sum",
-              "type" : "sum",
-              ...
-              "depends_on":["set_point","Filter"]
-            }
-          ]
-        }
-```
-
-## Blocks
-
-Blocks are configured similarly and share some common fields:
-
-- `name` - Name is unique and should be used for dependencies
-- `type` - Type of the block (see supported blocks)
-- `attributes` - The attributes of the block
-- `depends_on` - The list of blocks that this block depends on
-
-### Gain
-
-The Gain block multiplies a signal by the set gain. S_out = S_in \* Gain
-
-```json
-{
-  "name": "Gain",
-  "type": "gain",
-  "attributes": {
-    "gain": 0.00392156862
-  },
-  "depends_on": ["PID"]
-}
-```
-
-### Constant
-
-The Constant block outputs a constant signal. S_out = Cte
-
-```json
-{
-  "name": "SetPoint",
-  "type": "constant",
-  "attributes": {
-    "constant_val": 0.0
-  }
-}
-```
-
-### Endpoint
-
-The Endpoint is a special type of block that is used to represent a plant.
-For now, only DC motors with an encoder, and a base with a linear and angular movement sensor are supported as an endpoint in the control package.
-You should change the _motor_name_ attribute to _base_name_ when using a base.
-
-```json
-{
-  "name": "Endpoint",
-  "type": "endpoint",
-  "attributes": {
-    "motor_name": "m-j1"
-  },
-  "depends_on": [""]
-}
-```
-
-### PID
-
-PID (Proportional Integral Derivative) is a widely used method to control a process variable.
-The PID takes as input the error (equal to _SP - PV_), and calculates a value that can be fed back into the endpoint.
-The mathematical form of a PID is:
-
-u(t) = Kp\*e(t) + Ki\*int(e(t))\*dt + Kd\*(de(t)/dt)
-
-Where:
-
-- Kp, Ki, and Kd are the PID gains
-- e(t) is the error at time t
-- dt the time elapsed between two successive steps.
-
-Finding the proper gains for a PID controller can be quite difficult.
-There are two main approaches that one can use:
-
-1. **Manual Tuning** - With this approach, the user tries different gains values and, using some visual feedback, adjusts them until a stable control can be achieved. In most cases this is not a suitable way to estimate gains.
-2. **System Identification** - With this approach, the user attempts to measure quantitative plant data and estimate the proper gains values from these characteristics.
-
-The following implementation records the step response of the plant and uses the relay method to estimate the ultimate gain (_Ku_) and oscillation period (_Tu_) of the plant.
-
-Several methods to calculate Kp, Ki and Kd are implemented:
-
-- ziegerNicholsPI
-- ziegerNicholsPID
-- ziegerNicholsPD
-- ziegerNicholsSomeOvershoot
-- ziegerNicholsNoOvershoot
-- cohenCoonsPI
-- cohenCoonsPID
-- tyreusLuybenPI
-- tyreusLuybenPID
-
-```json
-{
-    "name": "PID",
-    "type": "PID",
-    "attributes":{
-        "kP":0.0, # Set each gain to 0 to start the tuning process
-        "kI":0.0,
-        "kD":0.0,
-        "limit_up":255.0, # Maximum value of the PID
-        "limit_lo":-255.0,
-        "tune_ssr_value": 2.0, # Value used to detect steady state  1.0 - 2.0 is a sensible range
-        "tune_method":"ziegerNicholsSomeOvershoot", # method to calculate the gains
-        "tune_step_pct":0.35, # Size of the step
-        "int_sat_lim_up":255.0, # Anti wind-up
-        "int_sat_lim_lo":-255.0
-    },
-    "depends_on":[""]
-}
-```
-
-### Encoder to RPM
-
-Encoder to RPM converts encoder counts to rpm using ticks per rotation.
-
-```json
-{
-  "name": "Derivative",
-  "type": "encoderToRpm",
-  "attributes": {
-    "PulsesPerRevolution": 14
-  },
-  "depends_on": ["Endpoint"]
-}
-```
-
-### Sum
-
-Sum blocks sum a number of Signals following a set sum_string.
-
-```json
-{
-  "name": "Sum",
-  "type": "sum",
-  "attributes": {
-    "sum_string": "+-"
-  },
-  "depends_on": ["SetPoint", "Filter"]
-}
-```
-
-### Trapezoidal velocity profile generator
-
-Position control of a motor can be achieved using the Trapezoidal Velocity Profile generator.
-
-On receipt of a newly submitted set point, this block generates a velocity profile given the constraints set in the configuration.
-
-This velocity profile is divided into three phases: Acceleration, Constant Speed, and Deceleration.
-
-The generated profile is dynamically adjusted during the deceleration phase, ensuring the end position remains in the position window.
-
-The block also works as a deadband controller when the target position is reached, preventing the motor from moving outside of the position window.
-
-```json
-"name":"trapz",
-              "type":"trapezoidalVelocityProfile",
-              "attributes":{
-                "max_vel" : 4000.0,
-                "max_acc" : 30000,
-                "pos_window" : 10,
-                "kpp_gain" : 0.45
-              },
-              "depends_on":["set_point","endpoint"]
-}
-```
-
-## Example
-
-If you want to configure a control loop outside of the standard encoded motor or sensor-controlled base setup, you can create a custom config and tune it manually.
-
-### Using SetupPIDControlConfig
-
-The following is an example of how to manually set up and tune a control loop using the function [`SetupPIDControlConfig`](/operate/reference/controls-package/#setuppidcontrolconfig):
-
-```go
-// set the necessary options for a component
-options := control.Options{
-  LoopFrequency:             100.0,
-}
-
-// create the controlParams from the PID values
-// in this example, all 0 PID values will result in auto-tuning
-controlParams := []control.PIDConfig{{
-  Type: "",
-  P:    0.0,
-  I:    0.0,
-  D:    0.0,
-}}
-
-// auto tune motor if all ControlParameters are 0
-if controlParams[0].NeedsAutoTuning() {
-  options.NeedsAutoTuning = true
-}
-
-// use SetupPIDControlConfig to create the control config and tune the component if necessary
-pidLoop, err := control.SetupPIDControlConfig(convertedControlParams, "component", options, component, component.logger)
-if err != nil {
-  return err
-}
-
-// some attributes that may be of use after setup
-controlLoopConfig := pidLoop.ControlConf
-loop := pidLoop.ControlLoop
-blockNames := pidLoop.BlockNames
-```
-
-### Using a Custom Control Config
-
-The following is an example of how to manually set up and tune a control loop using the `UseCustomConfig` and `CompleteCustomConfig` options:
-
-```go
-// create a custom control config
-controlConfig := control.Config {
-  Blocks: []BlockConfig{
-    {
-      Name: "set_point",
-      Type: blockConstant,
-      Attribute: rdkutils.AttributeMap{
-        "constant_val": 0.0,
-      },
-    },
-    {
-      Name: "sum",
-      Type: blockSum,
-      Attribute: rdkutils.AttributeMap{
-        "sum_string": "+-",
-      },
-      DependsOn: []string{"set_point", "endpoint"},
-    },
-    {
-      Name: "PID",
-      Type: blockPID,
-      Attribute: rdkutils.AttributeMap{
-        "int_sat_lim_lo": -255.0,
-        "int_sat_lim_up": 255.0,
-        "kD":             pidVals.D,
-        "kI":             pidVals.I,
-        "kP":             pidVals.P,
-        "limit_lo":       -255.0,
-        "limit_up":       255.0,
-        "tune_method":    "ziegerNicholsPI",
-        "tune_ssr_value": 2.0,
-        "tune_step_pct":  0.35,
-      },
-      DependsOn: []string{"sum"},
-    },
-    {
-      Name: "endpoint",
-      Type: blockEndpoint,
-      Attribute: rdkutils.AttributeMap{
-        controllableType: endpointName,
-      },
-      DependsOn: []string{"gain"},
-    },
-  },
-  Frequency: 100.0,
-}
-
-// set the necessary options for your component
-options := control.Options{
-  UseCustomConfig:           true,
-  CompleteCustomConfig:      controlConfig,
-}
-
-// create PID control parameters
-controlParams := []control.PIDConfig{{
-  Type: "",
-  P:    0.0,
-  I:    0.0,
-  D:    0.0,
-}}
-
-// auto tune motor if all ControlParameters are 0
-if controlParams[0].NeedsAutoTuning() {
-  options.NeedsAutoTuning = true
-}
-
-// create PIDLoop struct
-pidLoop = &control.PIDLoop{
-  PIDVals:      controlParams,
-  ControlConf:  controlConf,
-  Options:      options,
-  Controllable: component,
-  logger:       component.logger,
-}
-
-// assign BlockNames
-pidLoop.BlockNames = make(map[string][]string, len(pidLoop.ControlConf.Blocks))
-for _, b := range pidLoop.ControlConf.Blocks {
-  pidLoop.BlockNames[string(b.Type)] = append(pidLoop.BlockNames[string(b.Type)], b.Name)
-}
-
-// run tuning method on the component
-cancelCtx, cancelFunc := context.WithCancel(context.Background())
-err := pidLoop.TunePIDLoop(cancelCtx, cancelFunc)
-
-// some attributes that may be of use after setup
-controlLoopConfig := pidLoop.ControlConf
-loop := pidLoop.ControlLoop
-blockNames := pidLoop.BlockNames
-```
diff --git a/docs/operate/reference/glossary.md b/docs/operate/reference/glossary.md
deleted file mode 100644
index 49d04d9f2c..0000000000
--- a/docs/operate/reference/glossary.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: "Glossary"
-linkTitle: "Glossary"
-weight: 900
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/glossary/"
----
diff --git a/docs/operate/reference/kinematic-chain-config.md b/docs/operate/reference/kinematic-chain-config.md
deleted file mode 100644
index bf34fbc4bd..0000000000
--- a/docs/operate/reference/kinematic-chain-config.md
+++ /dev/null
@@ -1,319 +0,0 @@
----
-title: "Configure complex kinematic chains"
-linkTitle: "Complex kinematic chains"
-weight: 200
-type: "docs"
-description: "Define kinematic parameters to configure intermediate reference frames for components with complex kinematic chains."
-tags: ["slam", "services"]
-date: "2022-01-01"
-updated: "2024-10-21"
-no_list: true
-aliases:
-  - /internals/kinematic-chain-config/
-# SMEs: Motion
----
-
-If you are developing a new {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}} to support a component with a complex kinematic chain (for example, a new robotic arm model), you need to add a file to your driver that details the attachment of the intermediate reference frames on the component.
-
-The [motion service](/operate/reference/services/motion/) uses these intermediate reference frames when calculating movements.
-
-For example, an [arm](/operate/reference/components/arm/) has a reference frame originating where the arm is attached to a surface, but it also has links and joints whose frames of reference matter when attempting to move the arm to a [pose](/motion-planning/reference/orientation-vectors/) with [`MoveToPosition()`](/reference/apis/components/arm/#movetoposition).
-
-This file can be a JSON file like [this xArm6 file](https://github.com/viam-modules/viam-ufactory-xarm/blob/main/arm/xarm6_kinematics.json), or a [<file>.URDF</file> file](https://industrial-training-master.readthedocs.io/en/melodic/_source/session3/Intro-to-URDF.html).
-
-## Kinematic parameters
-
-Viam supports two formats for supplying kinematic parameters to configure intermediate reference frames for a kinematic chain, defined as `"kinematic_param_type"`:
-
-1. [Spatial Vector Algebra (SVA)](https://drake.mit.edu/doxygen_cxx/group__multibody__spatial__vectors.html): supplying reference frame information for each `link` and each `joint`.
-2. [Denavit-Hartenberg (DH)](https://en.wikipedia.org/wiki/Denavit%E2%80%93Hartenberg_parameters) parameters.
-
-Of the two methods, we prefer Spatial Vector Algebra over Denavit-Hartenberg because it allows you to specify link frames arbitrarily, which DH parameters are unable to guarantee.
-Additionally, if you are making your own robot and defining new drivers, incorrect SVA parameters are easier to troubleshoot than incorrect DH parameters.
-
-{{% alert title="Info" color="info" %}}
-
-These reference frames are ingested by the frame system.
-They are not exposed in the [client SDKs](/reference/sdks/), with one exception.
-If your resource is an [arm component](/operate/reference/components/arm/), you can use the [`GetKinematics()`](/reference/apis/components/arm/#getkinematics) method to access its kinematics information.
-
-{{% /alert %}}
-
-This is an example configuration that is used by the [`ur5e` arm model](https://github.com/viam-modules/universal-robots/blob/main/src/kinematics/ur5e.json):
-
-{{< tabs name="Kinematic Parameter Types" >}}
-{{% tab name="SVA" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "UR5e",
-  "kinematic_param_type": "SVA",
-  "links": [
-    {
-      "id": "base_link",
-      "parent": "world",
-      "translation": {
-        "x": 0,
-        "y": 0,
-        "z": 162.5
-      },
-      "geometry": {
-        "x": 120,
-        "y": 120,
-        "z": 260,
-        "translation": {
-          "x": 0,
-          "y": 0,
-          "z": 130
-        }
-      }
-    },
-    {
-      "id": "shoulder_link",
-      "parent": "shoulder_pan_joint",
-      "translation": {
-        "x": 0,
-        "y": 0,
-        "z": 0
-      }
-    },
-    {
-      "id": "upper_arm_link",
-      "parent": "shoulder_lift_joint",
-      "translation": {
-        "x": -425,
-        "y": 0,
-        "z": 0
-      },
-      "geometry": {
-        "x": 550,
-        "y": 150,
-        "z": 120,
-        "translation": {
-          "x": -215,
-          "y": -130,
-          "z": 0
-        }
-      }
-    },
-    {
-      "id": "forearm_link",
-      "parent": "elbow_joint",
-      "translation": {
-        "x": -392.2,
-        "y": 0,
-        "z": 0
-      },
-      "geometry": {
-        "x": 480,
-        "y": 120,
-        "z": 100,
-        "translation": {
-          "x": -190,
-          "y": 0,
-          "z": 0
-        }
-      }
-    },
-    {
-      "id": "wrist_1_link",
-      "parent": "wrist_1_joint",
-      "translation": {
-        "x": 0,
-        "y": -133.3,
-        "z": 0
-      },
-      "geometry": {
-        "x": 90,
-        "y": 130,
-        "z": 130,
-        "translation": {
-          "x": 0,
-          "y": -110,
-          "z": 0
-        }
-      }
-    },
-    {
-      "id": "wrist_2_link",
-      "parent": "wrist_2_joint",
-      "translation": {
-        "x": 0,
-        "y": 0,
-        "z": -99.7
-      },
-      "geometry": {
-        "x": 80,
-        "y": 150,
-        "z": 100,
-        "translation": {
-          "x": 0,
-          "y": 0,
-          "z": -100
-        }
-      }
-    },
-    {
-      "id": "ee_link",
-      "parent": "wrist_3_joint",
-      "translation": {
-        "x": 0,
-        "y": -99.6,
-        "z": 0
-      },
-      "orientation": {
-        "type": "ov_degrees",
-        "value": {
-          "x": 0,
-          "y": -1,
-          "z": 0,
-          "th": 90
-        }
-      }
-    }
-  ],
-  "joints": [
-    {
-      "id": "shoulder_pan_joint",
-      "type": "revolute",
-      "parent": "base_link",
-      "axis": {
-        "x": 0,
-        "y": 0,
-        "z": 1
-      },
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "shoulder_lift_joint",
-      "type": "revolute",
-      "parent": "shoulder_link",
-      "axis": {
-        "x": 0,
-        "y": -1,
-        "z": 0
-      },
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "elbow_joint",
-      "type": "revolute",
-      "parent": "upper_arm_link",
-      "axis": {
-        "x": 0,
-        "y": -1,
-        "z": 0
-      },
-      "max": 180,
-      "min": -180
-    },
-    {
-      "id": "wrist_1_joint",
-      "type": "revolute",
-      "parent": "forearm_link",
-      "axis": {
-        "x": 0,
-        "y": -1,
-        "z": 0
-      },
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "wrist_2_joint",
-      "type": "revolute",
-      "parent": "wrist_1_link",
-      "axis": {
-        "x": 0,
-        "y": 0,
-        "z": -1
-      },
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "wrist_3_joint",
-      "type": "revolute",
-      "parent": "wrist_2_link",
-      "axis": {
-        "x": 0,
-        "y": -1,
-        "z": 0
-      },
-      "max": 360,
-      "min": -360
-    }
-  ]
-}
-```
-
-{{< /tab >}}
-{{% tab name="DH" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "UR5e",
-  "kinematic_param_type": "DH",
-  "dhParams": [
-    {
-      "id": "base",
-      "parent": "world",
-      "a": 0,
-      "d": 162.5,
-      "alpha": 1.57079632679,
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "shoulder",
-      "parent": "base",
-      "a": -425,
-      "d": 0,
-      "alpha": 0,
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "elbow",
-      "parent": "shoulder",
-      "a": -392.2,
-      "d": 0,
-      "alpha": 0,
-      "max": 180,
-      "min": -180
-    },
-    {
-      "id": "wrist_1",
-      "parent": "elbow",
-      "a": 0,
-      "d": 133.3,
-      "alpha": 1.57079632679,
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "wrist_2",
-      "parent": "wrist_1",
-      "a": 0,
-      "d": 99.7,
-      "alpha": -1.57079632679,
-      "max": 360,
-      "min": -360
-    },
-    {
-      "id": "wrist_3",
-      "parent": "wrist_2",
-      "a": 0,
-      "d": 99.6,
-      "alpha": 0,
-      "max": 360,
-      "min": -360
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
diff --git a/docs/operate/reference/prepare/_index.md b/docs/operate/reference/prepare/_index.md
deleted file mode 100644
index 088c741ce3..0000000000
--- a/docs/operate/reference/prepare/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-linkTitle: "Prepare Devices"
-title: "Prepare Devices"
-weight: 95
-empty_node: true
-layout: "empty"
-canonical: "/operate/install/setup/"
-type: "docs"
-toc_hide: true
----
diff --git a/docs/operate/reference/prepare/beaglebone-setup.md b/docs/operate/reference/prepare/beaglebone-setup.md
deleted file mode 100644
index 6aaa3ea4b3..0000000000
--- a/docs/operate/reference/prepare/beaglebone-setup.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: "BeagleBone AI-64 Setup Guide"
-linkTitle: "BeagleBone Setup"
-weight: 20
-type: "docs"
-description: "Flash a BeagleBone AI-64 to prepare it for viam-server installation."
-images: ["/installation/thumbnails/beaglebone.png"]
-imageAlt: "BeagleBone A I-64"
-no_list: true
-aliases:
-  - "/installation/beaglebone-install/"
-  - "/installation/prepare/beaglebone-install/"
-  - "/installation/prepare/beaglebone-setup/"
-  - /get-started/installation/prepare/beaglebone-setup/
-  - /get-started/prepare/beaglebone-setup/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: Shawn and Rand
----
-
-The [BeagleBone AI-64](https://docs.beagleboard.org/latest/boards/beaglebone/ai-64/) from [BeagleBoard.org](https://beagleboard.org/) is an open-source single-board computer with a Debian GNU/Linux operating system based on the Texas Instruments TDA4VM processor.
-Follow this guide to set up your BeagleBone AI-64 and prepare it for `viam-server` installation.
-
-<div class="td-max-width-on-larger-screens text-center">
-{{< imgproc alt="The front of a BeagleBone AI-64 single-board computer at a 45° angle." src="/installation/beaglebone-setup/image4.png" resize="400x" declaredimensions=true >}}
-</div>
-
-## Hardware requirements
-
-You need the following hardware, tools, and software to install `viam-server` on a BeagleBone AI-64:
-
-1. A [BeagleBone AI-64](https://www.beagleboard.org/boards/beaglebone-ai-64)
-2. A 5V barrel jack (recommended) and/or USB-C power supply, to power the BeagleBone
-3. Ethernet cable and/or WiFi dongle, to establish network connection on the BeagleBone
-4. (Optional) A microSD card and a way to connect the microSD card to the computer (like a microSD slot or microSD reader)
-   - This is required if you need to set up your BeagleBone for the first time or update your BeagleBone to the latest software image.
-
-The following instructions mirror the instructions given in the [BeagleBoard Quick Start Guide](https://docs.beagleboard.org/latest/boards/beaglebone/ai-64/02-quick-start.html).
-
-If you want additional help setting up your BeagleBone, you can follow the guides there and return to the Viam docs after SSH'ing into your BeagleBone.
-
-## Power your BeagleBone
-
-Power your board by plugging a 5VDC power source into the BeagleBone's barrel jack.
-You can also power the BeagleBone with a USB-C cable, but a 5VDC power source is recommended for more reliable performance.
-
-If the board has power, the LED on the board labeled _PWR_ or _ON_ is lit steadily.
-
-## Enable a network connection
-
-You need to enable a network connection on your BeagleBone to install `viam-server` on it.
-You can do this in multiple ways:
-
-- Connect an ethernet cable to your BeagleBone's ethernet port.
-- If you are working on a macOS machine, use [internet sharing over USB](https://support.apple.com/guide/mac-help/share-internet-connection-mac-network-users-mchlp1540/mac) to share your connection.
-  After enabling the option on your machine, SSH into your BeagleBone and run `sudo dhclient usb1`.
-- If you are working on a Linux machine, read [these tips on enabling a network connection](https://elinux.org/Beagleboard:Terminal_Shells).
-- If your personal computer supports mDNS (Multicast DNS), you can check to see if your BeagleBone board has established a network connection by visiting [beaglebone.local](https://beaglebone.local).
-
-## SSH into your BeagleBone from your PC
-
-You can SSH into your BeagleBone by running the following command in your terminal:
-
-`ssh <your-username>@<your-hostname>.local`
-
-By default, the hostname, username and password on a BeagleBone are:
-
-- Hostname: `beaglebone`
-- Username: `debian`
-- Password: `temppwd`
-
-Therefore, if you are using the default settings on your BeagleBone, the command is:
-
-`ssh debian@beaglebone.local`
-
-## Update your BeagleBone
-
-After SSH'ing into your BeagleBone, verify all packages are up to date:
-
-`sudo apt update && sudo apt dist-upgrade && sudo reboot`
-
-## Next steps
-
-You have now installed an operating system on your BeagleBone.
-To use your BeagleBone, follow the [setup guide](/operate/install/setup/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
-
-## Troubleshooting
-
-If you experience any issues getting Viam working on your BeagleBone, consult the [BeagleBone documentation](https://docs.beagleboard.org/latest/boards/beaglebone/ai-64/02-quick-start.html) for help updating your BeagleBone.
-
-{{< snippet "social.md" >}}
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
diff --git a/docs/operate/reference/prepare/board1-setup.md b/docs/operate/reference/prepare/board1-setup.md
deleted file mode 100644
index 2b12702612..0000000000
--- a/docs/operate/reference/prepare/board1-setup.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: "<board-series-model> Setup Guide"
-linkTitle: "<board-series-model> Setup"
-weight: 16
-type: "docs"
-description: "Flash an <storage-medium> for the <board-series-model> to prepare it for viam-server installation."
-images: ["/installation/thumbnails/prepare.png"]
-imageAlt: "<board-series-model>"
-no_list: true
-draft: true
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-The [<board-series-model>](http://example.com) from <manufacturer/organization> is a <brief-board-description-including-features-and-specifications>.
-It supports <operating-systems-or-distributions> and is ideal for <use-cases-or-applications>.
-Follow this guide to set up your <board-series-model> and prepare it for `viam-server` installation.
-
-{{<imgproc src="installation/thumbnails/prepare.png" alt="The <board-series-model> single-board computer." resize="350x" declaredimensions=true >}}
-
-## Hardware requirements
-
-- Development machine: laptop or computer workstation
-- An [<board-series-model>](http://example.com) board
-- ...
-
-## Install OS
-
-The <board-series-model> boots from a <storage-medium>.
-You need to install an operating system on the <storage-medium> that you will use with your <board-series-model>.
-
-<Viam-specific-OS-installation-instructions OR link-to-board-OS-installation-guide-from-company>
-
-## Power your <board-series-model>
-
-To power your <board-series-model>, connect your power adapter to the board's <port-type> port.
-The LED should light up, which indicates that the board is powered.
-
-{{% alert title="Tip" color="tip" %}}
-
-If your board's LED does not light up when powered, try re-flashing your <storage-medium> or using a different <storage-medium>.
-
-{{% /alert %}}
-
-To connect to a display, connect the <HDMI/micro-HDMI> end of your HDMI cable to the <board> and the other end to your monitor.
-Then, to connect the keyboard and mouse, plug the two devices into your computer's USB hub and connect the USB hub to your <board-series-model>'s <USB-type> port.
-
-## Establish a network connection
-
-You can plug the Ethernet cable into your <board-series-model> for a wired internet connection.
-For a wireless connection, you can <alternative-wireless-network-connection-methods>.
-
-### Update your <board-series-model>
-
-Once you're connected to your board, you can verify all packages are up to date by running the following command:
-
-`sudo apt update && sudo apt dist-upgrade && sudo reboot`
-
-## Next steps
-
-You have now installed an operating system on your BOARD.
-To use your BOARD, follow the [setup guide](/operate/install/setup/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
-
-## Troubleshooting
-
-If you experience any issues getting Viam to work on your <board-series-model>, consult the [<board-series-model> documentation](http://example.com).
-
-{{< snippet "social.md" >}}
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
diff --git a/docs/operate/reference/prepare/jetson-agx-orin-setup.md b/docs/operate/reference/prepare/jetson-agx-orin-setup.md
deleted file mode 100644
index cfaf406308..0000000000
--- a/docs/operate/reference/prepare/jetson-agx-orin-setup.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: "NVIDIA Jetson AGX Orin Setup Guide"
-linkTitle: "Jetson AGX Orin Setup"
-weight: 20
-type: "docs"
-images: ["/installation/thumbnails/jetson-agx-orin-dev-kit.png"]
-imageAlt: "Jetson A G X Orin Developer Kit"
-description: "Set up the Jetson AGX Orin Developer Kit to prepare your NVIDIA Jetson AGX Orin for viam-server installation."
-no_list: true
-aliases:
-  - /installation/prepare/jetson-agx-orin-setup/
-  - /get-started/installation/prepare/jetson-agx-orin-setup/
-  - /get-started/prepare/jetson-agx-orin-setup/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: Pete Garafano
----
-
-<div class="td-max-width-on-larger-screens text-center">
-{{<imgproc src="installation/thumbnails/jetson-agx-orin-dev-kit.png" alt="The grey and chunky front of the NVIDIA Jetson AGX Orin single-board computer development kit." resize="200x" declaredimensions=true >}}
-</div>
-
-The [Jetson AGX Orin](https://developer.nvidia.com/embedded/jetson-orin) from [NVIDIA](https://www.nvidia.com/) is a single-board computer that supports modern AI workloads and application development.
-Follow this guide to set up the [Jetson AGX Orin Developer Kit](https://developer.nvidia.com/embedded/learn/get-started-jetson-agx-orin-devkit) to prepare your NVIDIA Jetson AGX Orin for `viam-server` installation.
-
-<div style="clear:both;"><br /></div>
-
-{{< alert title="Important" color="note" >}}
-
-This guide assumes that you have a Jetson AGX Orin Developer Kit with a Jetson AGX Orin module and reference carrier board.
-If you want to use a different carrier board to incorporate your Orin into your machine, the type of carrier board you use will affect your hardware requirements.
-
-{{% /alert %}}
-
-{{% alert title="CAUTION: Use 3.3V inputs and outputs" color="caution" %}}
-
-The GPIO pins on Jetson boards are rated 3.3V signals. 5V signals from encoders and sensors can cause damage to a pin. We recommend selecting hardware that can operate 3.3V signals or lower.
-For details, see your board's specification.
-
-{{% /alert %}}
-
-## Hardware requirements
-
-You need the following hardware, tools, and software to install `viam-server` on a Jetson AGX Orin with the Jetson AGX Orin Developer Kit:
-
-**Initial setup with display attached:**
-
-1. A [Jetson AGX Orin Developer Kit](https://developer.nvidia.com/embedded/learn/get-started-jetson-agx-orin-devkit)
-2. A PC monitor (HDMI or DisplayPort)
-3. USB keyboard and mouse
-4. A DisplayPort to HDMI adapter/cable, to connect the Orin to the monitor
-5. USB Type-C power supply, to power the Orin (included with the AGX Orin Developer Kit)
-6. (Optional) Ethernet cable, to connect the Orin to the internet without Wifi access
-
-**Initial setup in headless mode:**
-
-1. A [Jetson AGX Orin Developer Kit](https://developer.nvidia.com/embedded/learn/get-started-jetson-agx-orin-devkit)
-2. An internet-connected Windows, Linux, or macOS computer
-3. A way to connect the computer to the Orin (for example, the USB Type-A to USB Type-C Cable included with the AGX Orin Developer Kit)
-
-   (Optional) If your computer doesn't have a USB Type-A port, you may need to attach a [USB-C hub](https://toomanyadapters.com/best-usb-hubs/) or similar device to your computer to connect to the Orin
-
-4. USB Type-C power supply, to power the Orin (included with the AGX Orin Developer Kit)
-5. (Optional) Ethernet cable, to connect the Orin to the internet without Wifi access
-
-## Jetson Orin setup guide
-
-Follow the instructions in [Getting Started with Jetson AGX Orin Developer Kit](https://developer.nvidia.com/embedded/learn/get-started-jetson-agx-orin-devkit) to boot up your Orin for the first time.
-
-If you have already booted up your Orin, start with "Step 2 - Install JetPack Components" to make sure you have installed the latest NVIDIA JetPack components.
-
-{{< alert title="Note" color="note" >}}
-Some vision services in the [registry](https://app.viam.com/registry) require you to install Jetpack 6 on your Jetson AGX Orin.
-If you intend to use GPIO, however, we recommend installing Jetpack 5 on your Jetson AGX Orin.
-{{< /alert >}}
-
-Look at the Troubleshooting section below for help navigating these instructions.
-Once you have reached _Next Steps_, return to the Viam docs.
-
-{{< alert title="Tip: <code>viam-server</code> installation with <code>curl</code>" color="tip" >}}
-
-If `curl` is not installed on your Orin, run `sudo apt install curl` before downloading the `viam-server` binary.
-
-If this command fails, try using `wget https://storage.googleapis.com/packages.viam.com/apps/viam-server/viam-server-latest-aarch64.AppImage` to download the `viam-server` binary.
-
-{{% /alert %}}
-
-## Camera setup
-
-1. Install E-Con Systems [e-CAM20_CUOAGX](https://www.e-consystems.com/nvidia-cameras/jetson-agx-orin-cameras/full-hd-ar0234-color-global-shutter-camera.asp) AR0234 driver.
-   Consult the instructions you received when purchasing your device for more information.
-2. Ensure the driver has successfully installed by running `sudo dmesg | grep ar0234`. The output should include `ar0234 Detected Ar0234 sensor`.
-3. Connect the AR0234 camera module and daughterboard to the J509 port located at the bottom of the Developer Kit.
-4. Configure the camera as a [webcam](/operate/reference/components/camera/webcam/).
-
-## Serial communication protocol tips
-
-To change the pins that are in use for modes of serial communication, launch <file>jetson-io.py</file> with the following commands:
-
-```sh { class="command-line" data-prompt="$"}
-cd ~
-sudo /opt/nvidia/jetson-io/jetson-io.py
-```
-
-In the interactive menu that opens, select **Configure Jetson 40 Pin Header** and **Configure header pins manually** to select and deselect pins to enable use.
-For a Jetson AGX Orin, reference the following:
-
-<!-- prettier-ignore -->
-| Data Sheet ID | GPIO Header Pin | Viam Bus ID | `jetson-io.py` ID | `/dev` Path ID | Notes |
-| ------------- | --------------- | ----------- | ----------------- | ----------- | ----- |
-| I2C_GP2_DAT, I2C_GP2_CLK | 3, 5 | `7` | `i2c2` | `/dev/i2c-2` | |
-| I2C_GP5_DAT, I2C_GP5_CLK | 27, 28 | `1` | `i2c8` | `/dev/i2c-8` | |
-| SPI1_DOUT, SPI1_DIN, SPI1_SCK, SPI1_CS0, SPI1_CS1 | 19, 21, 23, 24, 26 | `0` | `spi1` | `/dev/spidev0.0`, `/dev/spidev0.1` | Must be enabled to use SPI bus, must add `spidev` to `/etc/modules` |
-
-Note that I2C buses do not need to be configured through <file>jetson-io.py</file>.
-See NVIDIA's documentation on [Configuring the Jetson Expansion Headers](https://docs.nvidia.com/jetson/archives/r35.1/DeveloperGuide/text/HR/ConfiguringTheJetsonExpansionHeaders.html) for more information.
-
-## Next steps
-
-You have now installed an operating system on your Jetson board.
-To use your Jetson board, follow the [setup guide](/operate/install/setup/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
-
-## Troubleshooting
-
-### Setup tips
-
-- NVIDIA Step 1 - Run through Ubuntu Setup (oem config)
-
-  - Headless Mode Tips:
-    - Once you reach **step e** which instructs you to connect through the host serial port, the instructions to connect are immediately under **step e**.
-      Follow those steps according to the type of computer you're using.
-    - After running `sudo screen`, note that the `Password` input prompt immediately following refers to your computer's system password.
-  - "Jetson Initial configuration" (oem-config) Command Prompt Tips:
-    - App Partition: default is fine.
-    - Nvomodel mode: default is fine.
-    - Chromium install: not necessary, you can skip.
-    - Signing into online accounts: not necessary, you can skip.
-
-- NVIDIA Step 2 - Install JetPack Components
-  - After running `sudo apt dist-upgrade`, if you are prompted with "Package distributor has shipped an updated version" hit `y` to install the updated version.
-  - Do not run `sudo apt install nvidia-jetpack` in your terminal until after `sudo reboot` has completed.
-  - If your board is powered off after `sudo reboot` has completed and refuses to turn on, disconnect and reconnect the power cable.
-  - It is normal for JetPack installation to take a very long time, up to an hour or more.
-- If you do not see an interactive menu after launching <file>jetson-io.py</file>, try resizing your window to a large size.
-
-### Install `curl`
-
-If `curl` is not installed on your Orin, run `sudo apt install curl` before downloading the `viam-server` binary.
-
-If this command fails, try using `wget https://storage.googleapis.com/packages.viam.com/apps/viam-server/viam-server-stable-aarch64.AppImage` to download the `viam-server` binary.
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
-
-{{< snippet "social.md" >}}
diff --git a/docs/operate/reference/prepare/jetson-nano-setup.md b/docs/operate/reference/prepare/jetson-nano-setup.md
deleted file mode 100644
index a0c9881be6..0000000000
--- a/docs/operate/reference/prepare/jetson-nano-setup.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: "NVIDIA Jetson Nano and Orin Nano Setup Guide"
-linkTitle: "Jetson Nano and Orin Nano Setup"
-weight: 20
-type: "docs"
-images: ["/installation/thumbnails/jetson-nano-dev-kit.png"]
-imageAlt: "Jetson Nano"
-description: "Prepare your Jetson Nano or Jetson Orin Nano for viam-server installation."
-no_list: true
-aliases:
-  - /installation/prepare/jetson-nano-setup/
-  - /get-started/installation/prepare/jetson-nano-setup/
-  - /get-started/prepare/jetson-nano-setup/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: Pete Garafano
----
-
-The [Jetson Nano](https://developer.nvidia.com/embedded/jetson-nano) and [Jetson Orin Nano](https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin) from [NVIDIA](https://www.nvidia.com/) are small computers built for embedded applications and capable of supporting modern AI workloads.
-Follow this guide to set up the [Jetson Nano Developer Kit](https://developer.nvidia.com/embedded/jetson-nano-developer-kit) or the [Jetson Orin Nano Developer Kit](https://developer.nvidia.com/embedded/jetson-agx-orin-developer-kit) to prepare your NVIDIA Jetson Nano for `viam-server` installation.
-
-<div class="td-max-width-on-larger-screens text-center">
-{{<imgproc src="installation/thumbnails/jetson-nano-dev-kit.png" resize="200x" alt="The front of the NVIDIA Jetson Nano single-board computer development kit.">}}
-{{<imgproc src="installation/thumbnails/jetson-orin-nano.jpeg" resize="200x" alt="The front of the NVIDIA Jetson Orin Nano single-board computer development kit.">}}
-</div>
-
-{{% alert title="Important" color="note" %}}
-
-This guide assumes that you have a Jetson Nano Developer Kit or a Jetson Orin Nano Developer Kit with a Jetson module and reference carrier board.
-If you want to use a different carrier board to incorporate your Nano into your machine, the type of carrier board you use will affect your hardware requirements.
-
-{{% /alert %}}
-
-{{% alert title="CAUTION: Use 3.3V inputs and outputs" color="caution" %}}
-
-The GPIO pins on Jetson boards are rated 3.3V signals. 5V signals from encoders and sensors can cause damage to a pin. We recommend selecting hardware that can operate 3.3V signals or lower. For details, see pages 1-3 of the [Jetson Nano Developer Kit 40-Pin Expansion Header GPIO Usage Considerations Applications Note](https://developer.nvidia.com/jetson-nano-developer-kit-40-pin-expansion-header-gpio-usage-considerations-applications-note).
-
-{{% /alert %}}
-
-## Hardware requirements
-
-You need the following hardware, tools, and software to install `viam-server` on a Jetson Nano or Jetson Orin Nano:
-
-**Initial setup with display attached:**
-
-1. A [Jetson Nano Developer Kit](https://developer.nvidia.com/embedded/jetson-nano-developer-kit) or [Jetson Orin Nano Developer Kit](https://developer.nvidia.com/embedded/jetson-agx-orin-developer-kit)
-2. A microSD card (32GB UHS-1 minimum recommended)
-3. A computer display (HDMI or DP) with a USB keyboard and mouse
-4. A way to connect the microSD card to the computer (like a microSD slot or microSD reader)
-5. Ethernet cable and/or Wifi dongle, to establish network connection on the Nano
-6. 5V-2A (Nano) or 9-19V (Orin Nano) DC power supply with barrel jack connector
-
-**Initial setup in headless mode:**
-
-1. A [Jetson Nano Developer Kit](https://developer.nvidia.com/embedded/jetson-nano-developer-kit) or [Jetson Orin Nano Developer Kit](https://developer.nvidia.com/embedded/jetson-agx-orin-developer-kit)
-2. A microSD card (32GB UHS-1 minimum recommended)
-3. An internet-connected computer
-4. A way to connect the computer to the Nano (like a USB 2.0 A-Male to Micro B Cable)
-5. A way to connect the microSD card to the computer (like a microSD slot or microSD reader)
-6. Ethernet cable and/or Wifi dongle, to establish network connection on the Nano
-7. 5V-2A (Nano) or 9-19V (Orin Nano) DC power supply with barrel jack connector
-
-## Nano setup guide
-
-Follow the instructions in [Getting Started with Jetson Nano Developer Kit](https://developer.nvidia.com/embedded/learn/get-started-jetson-nano-devkit) or [Getting Started with Jetson Orin Nano Developer Kit](https://developer.nvidia.com/embedded/learn/get-started-jetson-orin-nano-devkit).
-Once you have reached _Next Steps_, return to the Viam docs.
-
-{{< alert title="Note" color="note" >}}
-Some vision services in the [registry](https://app.viam.com/registry) require you to install Jetpack 6 on your Jetson AGX Orin.
-If you intend to use GPIO, however, we recommend installing Jetpack 5 on your Jetson AGX Orin.
-{{< /alert >}}
-
-## Serial communication protocol tips
-
-To change the pins that are in use for modes of serial communication, launch <file>jetson-io.py</file> with the following commands:
-
-```sh { class="command-line" data-prompt="$"}
-cd ~
-sudo /opt/nvidia/jetson-io/jetson-io.py
-```
-
-In the interactive menu that opens, select **Configure Jetson 40 Pin Header** and **Configure header pins manually** to select and deselect pins to enable use.
-For a Jetson Orin Nano, reference the following:
-
-<!-- prettier-ignore -->
-| GPIO Header Pin | Viam Bus ID | `jetson-io.py` ID |
-| ---------------| ----------- | ----------------- |
-| 3, 5 | `7` | `i2c2` |
-| 27, 28 | `1` | `i2c8` |
-| 19, 21, 23, 24, 26 | `0` | `spi1` |
-| 13, 16, 18, 22, 37 | `2` | `spi3` |
-| 15 | | `pwm1` |
-| 33 | | `pwm5` |
-
-Note that I2C buses do not need to be configured through <file>jetson-io.py</file>.
-See NVIDIA's documentation on [Configuring the Jetson Expansion Headers](https://docs.nvidia.com/jetson/archives/r35.1/DeveloperGuide/text/HR/ConfiguringTheJetsonExpansionHeaders.html) for more information.
-
-## Next steps
-
-You have now installed an operating system on your Jetson board.
-To use your Jetson board, follow the [setup guide](/operate/install/setup/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
-
-## Troubleshooting
-
-### Install `curl`
-
-If `curl` is not installed on your Orin, run `sudo apt install curl` before downloading the `viam-server` binary.
-
-If this command fails, try using `wget https://storage.googleapis.com/packages.viam.com/apps/viam-server/viam-server-stable-aarch64.AppImage` to download the `viam-server` binary.
-
-### Barrel jack power supply polarity
-
-Make sure the polarity on your barrel jack power supply is matched when powering your machine.
-See the last step of your appropriate [initial setup guide](#hardware-requirements) for instructions on choosing the correct power supply for your Nano board.
-
-If you do not see an interactive menu after launching <file>jetson-io.py</file>, try resizing your window to a large size.
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
-
-{{< snippet "social.md" >}}
diff --git a/docs/operate/reference/prepare/odroid-c4-setup.md b/docs/operate/reference/prepare/odroid-c4-setup.md
deleted file mode 100644
index a74c812816..0000000000
--- a/docs/operate/reference/prepare/odroid-c4-setup.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: "Odroid C4 Setup Guide"
-linkTitle: "Odroid-C4 Setup"
-weight: 16
-type: "docs"
-description: "Image a Odroid-C4 to prepare it for viam-server installation."
-images: ["/installation/thumbnails/odroid-c4.png"]
-imageAlt: "Odroid-C4"
-no_list: true
-aliases:
-  - /get-started/installation/prepare/odroid-c4-setup/
-  - /get-started/prepare/odroid-c4-setup/
-  - /installation/prepare/odroid-c4-setup/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SME: Olivia Miller
----
-
-The [Odroid-C4](https://wiki.odroid.com/odroid-c4/odroid-c4#odroid-c4) is a single-board computer that features an Amlogic S905x3 CPU and runs a variety of Linux or Android distributions.
-
-{{<imgproc src="installation/thumbnails/odroid-c4.png" alt="The Odroid-C4 single-board computer." resize="350x" declaredimensions=true >}}
-
-Follow this guide to set up your Odroid-C4.
-
-## Hardware requirements
-
-- An [Odroid-C4 board](https://www.hardkernel.com/shop/odroid-c4/)
-- A 12V/2A power supply
-- An ethernet cable and/or USB Wi-Fi dongle, for network connectivity
-- A computer, for development
-- A microSD card, if you plan to boot from SD instead of eMMC
-- (Optional) An HDMI cable, for display
-
-## Power your Odroid C4
-
-Before you power the board, you need to install an operating system.
-Visit [Odroid's OS Installation Guide](https://wiki.odroid.com/getting_started/os_installation_guide#os_installation_guide) to choose the right OS for your needs and follow the instructions to flash the OS to your microSD card or eMMC.
-
-To power your Odroid-C4, connect your power adapter to the Odroid-C4's power jack.
-The red LED should light up, which indicates that the board is powered.
-
-To connect to a display, connect one end of your HDMI cable to the Odroid and the other end to your monitor.
-
-## Establish a network connection
-
-Plug the Ethernet cable into your Odroid-C4for a wired internet connection.
-For a wireless connection, you can connect a USB Wi-Fi dongle and configure Wi-Fi settings through your operating system.
-
-## Access and update your Odroid-C4
-
-To access your Odroid remotely, use an SSH client like [TeraTerm](https://teratermproject.github.io/index-en.html).
-You'll also need the IP address of your Odroid-C4 board to connect remotely.
-Alternatively, connect a keyboard and mouse to interact with the board directly using a connected monitor.
-
-Once you're connected, open a terminal and run the following commands
-
-```sh {class="command-line" data-prompt="$"}
-sudo apt update && sudo apt upgrade
-```
-
-## Install `viam-server`
-
-{{< readfile "/static/include/install/install-linux.md" >}}
-
-## Try an example
-
-{{< readfile "/static/include/install/try-example.md" >}}
-
-## Next steps
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" %}}
-{{% card link="/operate/hello-world/tutorial-desk-safari/" %}}
-{{% card link="/tutorials/" %}}
-{{< /cards >}}
-
-## Troubleshooting
-
-Visit the [Odroid Forum](https://forum.odroid.com/index.php) for troubleshooting tips and tricks specific to the Odroid-C4.
diff --git a/docs/operate/reference/prepare/orange-pi-3-lts.md b/docs/operate/reference/prepare/orange-pi-3-lts.md
deleted file mode 100644
index c70fbfeb0a..0000000000
--- a/docs/operate/reference/prepare/orange-pi-3-lts.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: "Orange Pi 3 LTS Setup Guide"
-linkTitle: "Orange Pi 3 LTS Setup"
-weight: 16
-type: "docs"
-description: "Image an Orange Pi 3 LTS to prepare it for viam-server installation."
-images: ["/installation/thumbnails/orange-pi-3-LTS.png"]
-imageAlt: "Orange Pi 3 LTS"
-no_list: true
-aliases:
-  - /get-started/installation/prepare/orange-pi-3-lts/
-  - /get-started/prepare/orange-pi-3-lts/
-  - /installation/prepare/orange-pi-3-lts/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SME: Olivia Miller
----
-
-The [Orange Pi 3 LTS](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-2.html) is a highly compact, open-source single-board computer equipped with dual-band WiFi and Bluetooth 5.0.
-It can run Ubuntu, Android10, or Debian distributions.
-
-{{<imgproc src="installation/thumbnails/orange-pi-3-LTS.png" alt="The Orange Pi 3 LTS single-board computer." resize="350x" declaredimensions=true >}}
-
-Follow this guide to set up your Orange Pi 3 LTS to run `viam-server`.
-
-## Hardware requirements
-
-- Development machine: laptop or computer workstation
-- An [Orange Pi 3 LTS](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-3-LTS.html)
-- A 5V 3A power supply with a USB-C connector
-- A micro-SD card (TF card): Minimum of 8GB, 16GB recommended
-- [SD card reader](https://www.amazon.com/Reader-Beikell-Connector-Memory-Adapter/dp/B0BGNZGDTC/) (recommended with USB-C connector)
-- A monitor: for display
-- [HDMI cable](https://www.amazon.com/Highwings-Braided-Cord-Supports-ARC-Compatible-Ethernet/dp/B07TDH11BJ/): to connect Orange Pi to monitor display
-- USB keyboard and mouse
-- [USB-C to USB-A cables](https://www.amazon.com/Anker-2-Pack-Premium-Samsung-Galaxy/dp/B07DD5YHMH/): to connect keyboard and mouse to USB hub or Orange Pi ports (recommended, hardware dependent)
-- [USB hub](https://www.amazon.com/BYEASY-Extended-Portable-Splitter-MacBook/dp/B07TVH9NHP/) with USB-A connector (recommended)
-
-## Power your Orange Pi 3 LTS
-
-Before you power the board, you need to install an operating system.
-
-1. First, download an [Orange Pi 3 LTS Ubuntu image](https://drive.google.com/drive/folders/1KzyzyByev-fpZat7yvgYz1omOqFFqt1k) to your development machine.
-   We recommend `ubuntu_jammy_desktop`.
-1. Unzip the image.
-1. Insert the micro-SD card into the SD card reader and connect the reader to your development machine.
-1. Follow the [Orange Pi guide to prepare your microSD card](https://sbc-community.org/docs/general_guides/prepare_sd_card/) to flash the OS to your micro-SD card using [balenaEtcher](https://etcher.balena.io/).
-
-   {{< alert title="Tip: How to think about building a machine" color="tip" >}}
-   While flashing your microSD card, we recommend reading [How to think about building a machine](/operate/hello-world/building/).
-   {{< /alert >}}
-
-1. Insert the micro-SD into the Orange Pi.
-
-To power your Orange Pi 3 LTS, connect your power adapter to the LTS's USB-C port.
-The LED should light up, which indicates that the board is powered.
-
-{{% alert title="Tip" color="tip" %}}
-If your board's LED does not light up when powered, try re-flashing your micro-SD card with the `ubuntu_jammy_desktop` image or using a different micro-SD card.
-The Orange Pi will only power on with a compatible operating system installed.
-{{% /alert %}}
-
-To connect to a display, connect the HDMI cable to the Orange Pi's HDMI port and the other end to your monitor.
-Then, connect your keyboard and mouse to the two USB-A ports on your Orange Pi.
-Alternatively, you can connect your peripherals to a USB hub and connect the USB hub to your Orange Pi's USB-A port.
-
-{{% alert title="Tip" color="tip" %}}
-For board schematics, consult the [Orange Pi 3 LTS documentation](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-3-LTS.html).
-{{% /alert %}}
-
-Once the Orange Pi successfully boots, you should be greeted with the Orange Pi desktop display.
-If you are prompted for a login password, note that the default password for Orange Pi devices is "orangepi".
-
-## Establish a network connection
-
-The Orange Pi 3 LTS comes equipped with a wireless network antenna.
-To connect to WiFi through the desktop, click on the WiFi icon in the top right of the monitor display, select your preferred network or hotspot, and enter the password.
-
-{{% alert title="Tip" color="tip" %}}
-You can also connect to WiFi while connected to the Orange Pi on the terminal with several different methods, including the `nmcli` tool.
-For more information, consult the [official user manual](https://drive.google.com/file/d/1jka7avWnzNeTIQFkk78LoJdygWaGH2iu/view) (page 80).
-{{% /alert %}}
-
-## Next steps
-
-You have now installed an operating system on your Orange Pi.
-To use your Orange Pi, follow the [setup guide](/operate/install/setup/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
-
-If you want to use the GPIO pins on the board, add a [`orangepi` board as a component](https://github.com/viam-modules/orange-pi/) after installing `viam-server`.
-
-## Troubleshooting
-
-If you are prompted for a password in the terminal, the default password for Orange Pis is "orangepi".
-
-Visit the [Orange Pi Forum](http://www.orangepi.org/orangepibbsen/) for troubleshooting tips and tricks specific to the Orange Pi.
diff --git a/docs/operate/reference/prepare/orange-pi-zero2.md b/docs/operate/reference/prepare/orange-pi-zero2.md
deleted file mode 100644
index d8a61fa18f..0000000000
--- a/docs/operate/reference/prepare/orange-pi-zero2.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: "Orange Pi Zero2 Setup Guide"
-linkTitle: "Orange Pi Zero2 Setup"
-weight: 16
-type: "docs"
-description: "Image an Orange Pi Zero2 to prepare it for viam-server installation."
-images: ["/installation/thumbnails/orange-pi-zero2.png"]
-imageAlt: "Orange Pi Zero2"
-no_list: true
-aliases:
-  - /get-started/installation/prepare/orange-pi-zero2/
-  - /get-started/prepare/orange-pi-zero2/
-  - /installation/prepare/orange-pi-zero2/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SME: Olivia Miller
----
-
-The [Orange Pi Zero2](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-2.html) is a highly compact, open-source single-board computer equipped with dual-band WiFi and Bluetooth 5.0.
-It can run Ubuntu, Android10, or Debian distributions.
-
-{{<imgproc src="installation/thumbnails/orange-pi-zero2.png" alt="The Orange Pi Zero2 single-board computer." resize="350x" declaredimensions=true >}}
-
-Follow this guide to set up your Orange Pi Zero2 to run `viam-server`.
-
-## Hardware requirements
-
-- Development machine: laptop or computer workstation
-- An [Orange Pi Zero2](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-Zero-2.html)
-- A 5V 3A power supply with a USB-C connector
-- A microSD card: Minimum of 8GB, 16GB recommended
-- [SD card reader](https://www.amazon.com/Reader-Beikell-Connector-Memory-Adapter/dp/B0BGNZGDTC/) (recommended with USB-C connector)
-- A monitor: for display
-- [Micro-HDMI to HDMI cable](https://www.amazon.com/Amazon-Basics-Flexible-Durable-18Gpbs/dp/B07KSDB25X/): to connect Orange Pi to monitor display
-- USB keyboard and mouse
-- [USB-C to USB-A cables](https://www.amazon.com/Anker-2-Pack-Premium-Samsung-Galaxy/dp/B07DD5YHMH/): to connect keyboard and mouse to USB hub
-- [USB hub](https://www.amazon.com/BYEASY-Extended-Portable-Splitter-MacBook/dp/B07TVH9NHP/) with USB-A connector (recommended)
-
-## Power your Orange Pi Zero2
-
-Before you power the board, you need to install an operating system.
-
-1. First, download an [Orange Pi Ubuntu image](https://drive.google.com/drive/folders/1ohxfoxWJ0sv8yEHbrXL1Bu2RkBhuCMup) to your development machine.
-   We recommend `ubuntu_jammy_desktop`.
-1. Unzip the image.
-1. Insert the micro-SD card into the SD card reader and connect the reader to your development machine.
-1. Follow [this guide](https://sbc-community.org/docs/general_guides/prepare_sd_card/) to flash the OS to your micro-SD card using [balenaEtcher](https://etcher.balena.io/).
-   {{< alert title="Tip: How to think about building a machine" color="tip" >}}
-   While flashing your microSD card, we recommend reading [How to think about building a machine](/operate/hello-world/building/).
-   {{< /alert >}}
-1. Insert the micro-SD into the Orange Pi.
-
-To power your Orange Pi Zero2, connect your power adapter to the Zero2's USB-C port.
-The LED should light up, which indicates that the board is powered.
-
-{{% alert title="Tip" color="tip" %}}
-If your board's LED does not light up when powered, try re-flashing your micro-SD card with the `ubuntu_jammy_desktop` image or using a different micro-SD card.
-The Orange Pi will only power on with a compatible operating system installed.
-{{% /alert %}}
-
-To connect to a display, connect the micro-HDMI end of your HDMI cable to the Orange Pi and the other end to your monitor.
-Then, to connect the keyboard and mouse, plug the two devices into your USB hub and connect the USB hub to your Orange Pi's USB-A port.
-
-After it boots, you should be greeted with the Orange Pi desktop display.
-If it prompts you for a password, note that the default password for Orange Pi devices is "orangepi".
-
-## Establish a network connection
-
-The Orange Pi Zero2 comes equipped with a wireless network antenna.
-To connect to WiFi, click on the WiFi icon in the top right of the monitor display, select your preferred network or hotspot, and enter the password.
-
-{{% alert title="Tip" color="tip" %}}
-You can also connect to WiFi while connected to the Orange Pi on the terminal with several different methods, including the `nmcli` tool.
-For more information, consult the [official user manual](https://drive.google.com/file/d/1jka7avWnzNeTIQFkk78LoJdygWaGH2iu/view) (page 80).
-{{% /alert %}}
-
-## Next steps
-
-You have now installed an operating system on your Orange Pi.
-To use your Orange Pi, follow the [setup guide](/operate/install/setup/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
-
-If you want to use the GPIO pins on the board, add a [`orangepi` board as a component](https://github.com/viam-modules/orange-pi/) after installing `viam-server`.
-
-## Troubleshooting
-
-If you are prompted for a password in the terminal, the default password for Orange Pis is "orangepi".
-
-Visit the [Orange Pi Forum](http://www.orangepi.org/orangepibbsen/) for troubleshooting tips and tricks specific to the Orange Pi.
diff --git a/docs/operate/reference/prepare/pumpkin.md b/docs/operate/reference/prepare/pumpkin.md
deleted file mode 100644
index 74f8e9c55a..0000000000
--- a/docs/operate/reference/prepare/pumpkin.md
+++ /dev/null
@@ -1,264 +0,0 @@
----
-title: "Pumpkin Board Setup Guide"
-linkTitle: "Pumpkin Board Setup"
-weight: 25
-type: "docs"
-images: ["/installation/thumbnails/pumpkin.png"]
-imageAlt: "Pumpkin board"
-description: "Configure the pin mappings to use a pumpkin board."
-no_list: true
-aliases:
-  - /installation/prepare/pumpkin/
-  - /get-started/installation/prepare/pumpkin/
-  - /get-started/prepare/pumpkin/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-To use a [Mediatek Genio 500 Pumpkin single-board computer](https://ologicinc.com/portfolio/mediateki500/) with Viam:
-
-1. [Install `viam-server`](/operate/install/setup/) on your machine.
-1. [Create a board definitions file](#create-a-board-definitions-file), specifying the mapping between your board's GPIO pins and connected hardware.
-1. [Configure a `customlinux` board](#configure-a-customlinux-board) on your machine, specifying the path to the definitions file in the board configuration.
-
-## Create a board definitions file
-
-The board definitions file describes the location of each GPIO pin on the board so that `viam-server` can access the pins correctly.
-
-On your Pumpkin board, create a JSON file in the <file>/home/root</file> directory named <file>board.json</file>, and provide the mappings between your GPIO pins and connected hardware.
-Use the template and example below to populate the JSON file with a single key, `"pins"`, whose value is a list of objects that each represent a pin on the board.
-
-```json
-{
-  "pins": [
-    {
-      "name": "3",
-      "device_name": "gpiochip0",
-      "line_number": 81,
-      "pwm_id": -1
-    },
-    {
-      "name": "5",
-      "device_name": "gpiochip0",
-      "line_number": 84,
-      "pwm_id": -1
-    },
-    {
-      "name": "7",
-      "device_name": "gpiochip0",
-      "line_number": 150,
-      "pwm_id": -1
-    },
-    {
-      "name": "11",
-      "device_name": "gpiochip0",
-      "line_number": 173,
-      "pwm_id": -1
-    },
-    {
-      "name": "13",
-      "device_name": "gpiochip0",
-      "line_number": 152,
-      "pwm_id": -1
-    },
-    {
-      "name": "15",
-      "device_name": "gpiochip0",
-      "line_number": 94,
-      "pwm_id": -1
-    },
-    {
-      "name": "19",
-      "device_name": "gpiochip0",
-      "line_number": 163,
-      "pwm_id": -1
-    },
-    {
-      "name": "21",
-      "device_name": "gpiochip0",
-      "line_number": 161,
-      "pwm_id": -1
-    },
-    {
-      "name": "23",
-      "device_name": "gpiochip0",
-      "line_number": 164,
-      "pwm_id": -1
-    },
-    {
-      "name": "27",
-      "device_name": "gpiochip0",
-      "line_number": 82,
-      "pwm_id": -1
-    },
-    {
-      "name": "29",
-      "device_name": "gpiochip0",
-      "line_number": 98,
-      "pwm_id": -1
-    },
-    {
-      "name": "31",
-      "device_name": "gpiochip0",
-      "line_number": 12,
-      "pwm_id": -1
-    },
-    {
-      "name": "33",
-      "device_name": "gpiochip0",
-      "line_number": 101,
-      "pwm_id": -1
-    },
-    {
-      "name": "35",
-      "device_name": "gpiochip0",
-      "line_number": 171,
-      "pwm_id": -1
-    },
-    {
-      "name": "37",
-      "device_name": "gpiochip0",
-      "line_number": 169,
-      "pwm_id": -1
-    },
-    {
-      "name": "8",
-      "device_name": "gpiochip0",
-      "line_number": 115,
-      "pwm_id": -1
-    },
-    {
-      "name": "10",
-      "device_name": "gpiochip0",
-      "line_number": 121,
-      "pwm_id": -1
-    },
-    {
-      "name": "12",
-      "device_name": "gpiochip0",
-      "line_number": 170,
-      "pwm_id": -1
-    },
-    {
-      "name": "16",
-      "device_name": "gpiochip0",
-      "line_number": 165,
-      "pwm_id": -1
-    },
-    {
-      "name": "18",
-      "device_name": "gpiochip0",
-      "line_number": 1,
-      "pwm_id": -1
-    },
-    {
-      "name": "22",
-      "device_name": "gpiochip0",
-      "line_number": 2,
-      "pwm_id": -1
-    },
-    {
-      "name": "24",
-      "device_name": "gpiochip0",
-      "line_number": 162,
-      "pwm_id": -1
-    },
-    {
-      "name": "26",
-      "device_name": "gpiochip0",
-      "line_number": 0,
-      "pwm_id": -1
-    },
-    {
-      "name": "28",
-      "device_name": "gpiochip0",
-      "line_number": 83,
-      "pwm_id": -1
-    },
-    {
-      "name": "32",
-      "device_name": "gpiochip0",
-      "line_number": 97,
-      "pwm_id": -1
-    },
-    {
-      "name": "36",
-      "device_name": "gpiochip0",
-      "line_number": 151,
-      "pwm_id": -1
-    },
-    {
-      "name": "38",
-      "device_name": "gpiochip0",
-      "line_number": 174,
-      "pwm_id": -1
-    },
-    {
-      "name": "40",
-      "device_name": "gpiochip0",
-      "line_number": 172,
-      "pwm_id": -1
-    }
-  ]
-}
-```
-
-## Configure a `customlinux` board
-
-Configure your board as a [`customlinux`](https://app.viam.com/module/viam/customlinux) board to use your board definitions file:
-
-{{< tabs name="Configure a customlinux board" >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `board` type, then select the `customlinux` model.
-Enter a name or use the suggested name for your `customlinux` board and click **Create**.
-
-[Example configuration for a pumpkin board using customlinux](https://github.com/viam-modules/customlinux/blob/main/README.md#example-configuration-for-a-pumpkin-board)
-
-Copy and paste the following json object into your board's attributes field.
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "board_defs_file_path": "/home/root/board.json"
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "myCustomBoard",
-      "model": "customlinux",
-      "api": "rdk:component:board",
-      "attributes": {
-        "board_defs_file_path": "/home/root/board.json"
-      },
-      "depends_on": []
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Try an example
-
-{{< readfile "/static/include/install/try-example.md" >}}
-
-## Next steps
-
-{{< cards >}}
-{{% card link="/operate/modules/configure-modules/" %}}
-{{% card link="/operate/hello-world/tutorial-desk-safari/" %}}
-{{% card link="/tutorials/" %}}
-{{< /cards >}}
-
-## Need assistance?
-
-{{< snippet "social.md" >}}
diff --git a/docs/operate/reference/prepare/rpi-setup.md b/docs/operate/reference/prepare/rpi-setup.md
deleted file mode 100644
index 5ffbb49eb2..0000000000
--- a/docs/operate/reference/prepare/rpi-setup.md
+++ /dev/null
@@ -1,193 +0,0 @@
----
-title: "Raspberry Pi Setup Guide"
-linkTitle: "Raspberry Pi Setup"
-weight: 15
-type: "docs"
-description: "Image a Raspberry Pi to prepare it for viam-server installation."
-images: ["/installation/thumbnails/raspberry-pi-4-b-2gb.png"]
-imageAlt: "Raspberry Pi"
-no_list: true
-aliases:
-  - /getting-started/rpi-setup/
-  - /installation/rpi-setup/
-  - /installation/prepare/rpi-setup/
-  - /get-started/installation/prepare/rpi-setup/
-  - /get-started/prepare/rpi-setup/
-  - /operate/reference/prepare/rpi-enable-protocols/
-  - /operate/reference/prepare/wifi-credentials/
-# SME: James
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-{{<youtube embed_url="https://www.youtube-nocookie.com/embed/drl2p2of-qA">}}
-
-We recommend using Viam on a 64-bit Linux distribution.
-Support for older Raspberry Pis running on 32-bit ARM v7 is in beta.
-
-If you already have a Linux distribution installed on your {{< glossary_tooltip term_id="pi" text="Pi" >}}, you can skip ahead to [install `viam-server`](/operate/install/setup/).
-
-{{% expand "Click to check whether the Linux installation on your Raspberry Pi is 64-bit or 32-bit" %}}
-
-To check whether the Linux installation on your Raspberry Pi is 64-bit or 32-bit, `ssh` into your Pi and then run `lscpu`.
-
-Example output:
-
-{{< imgproc alt="Screenshot of a terminal running the 'lscpu' command. The output lists of this command on a Raspberry Pi. A red box highlights the command and the top of the output which reads 'Architecture: aarch64.'" src="/installation/rpi-setup/lscpu-output.png" resize="800x" declaredimensions=true class="shadow" >}}
-
-If the value of "Architecture: _'xxxxxx'_" ends in "64", you can skip ahead to [install `viam-server`](/operate/install/setup/).
-
-{{% /expand%}}
-
-## Hardware requirements
-
-- A [Raspberry Pi single-board computer](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/)
-- A microSD card
-- An internet-connected computer
-- A way to connect the microSD card to the computer (microSD slot or microSD reader)
-
-## Install Raspberry Pi OS
-
-The Raspberry Pi boots from a microSD card.
-You need to install Raspberry Pi OS (formerly called Raspbian) on the microSD card you will use with your Pi:
-
-1. Connect the microSD card to your computer.
-
-1. Download the [Raspberry Pi Imager](https://www.raspberrypi.com/software/) and launch it.
-
-   {{< imgproc alt="Raspberry Pi Imager launcher window showing a 'Choose OS' and 'Choose Storage' buttons." src="/installation/rpi-setup/imager-launch-screen.png" resize="800x" declaredimensions=true class="shadow" >}}
-
-1. Click **CHOOSE DEVICE**.
-   Select your model of Pi.
-
-   {{< imgproc alt="Raspberry Pi Imager window showing available pi models." src="/installation/rpi-setup/select-pi-models.png" resize="800x" declaredimensions=true class="shadow" >}}
-
-1. Click **CHOOSE OS**.
-   Select **Raspberry Pi OS (other)**.
-
-   {{< imgproc alt="Raspberry Pi Imager window showing Raspberry Pi OS (Other) is selected." src="/installation/rpi-setup/select-other-custom-os.png" resize="800x" declaredimensions=true class="shadow" >}}
-
-   Select **Raspberry Pi OS Full (64-bit)** or **Raspberry Pi OS Full (32-bit)** from the menu.
-
-   {{< imgproc alt="Raspberry Pi Imager window showing Raspberry Pi OS (Legacy, 64-bit) Full is selected." src="/installation/rpi-setup/select-other-rpi.png" resize="800x" declaredimensions=true class="shadow"  >}}
-
-   You should be brought back to the initial launch screen.
-
-1. Click **CHOOSE STORAGE**.
-   From the list of devices, select the microSD card you intend to use in your Raspberry Pi.
-
-   If no devices are listed, make sure your microSD card is connected to your computer correctly.
-
-   {{< imgproc alt="The storage screen is shown with a generic SD card available as an option." src="/installation/rpi-setup/imager-select-storage.png" resize="800x" declaredimensions=true class="shadow"  >}}
-
-1. Configure your Raspberry Pi for remote access.
-   Click **Next**.
-   When prompted to apply OS customization settings, select **EDIT SETTINGS**.
-
-   {{< imgproc alt="Raspberry Pi Imager window showing gear-shaped settings icon is selected." src="/installation/rpi-setup/advanced-options.png" resize="800x" declaredimensions=true class="shadow"  >}}
-
-   {{% alert title="Important" color="note" %}}
-
-   If you are using a non-Raspberry Pi OS, altering the OS customization settings will cause the initial boot to fail.
-
-   {{% /alert %}}
-
-   Check **Set hostname** and enter the name you would like to access the Pi by in that field:
-
-   {{< imgproc alt="Raspberry Pi Imager window showing the advanced options menu with set hostname checked and set to my-machine.local." src="/installation/rpi-setup/imager-set-hostname.png" resize="600x" declaredimensions=true class="shadow"  >}}
-
-   There are two ways you can secure your Raspberry Pi: with an SSH key or with password authentication.
-
-   - For a learning project or a fun hobby project, we recommend using password authentication because it is easiest to set up for first-time users.
-   - For production use, we recommend using SSH keys for more secure authentication; only someone with the private SSH key will be able to authenticate to your system.
-
-   {{< tabs >}}
-
-{{% tab name="Password" %}}
-
-1. Select the checkbox next to **Set username and password** and set a username (for example, your first name) and a unique password that you will use to log into the Pi:
-
-   {{< imgproc alt="Raspberry Pi Imager window showing the 'Set username and password' option is selected. The user has entered username 'Robota' and some hidden password." src="/installation/rpi-setup/imager-set-passwordauthentication.png" resize="550x" declaredimensions=true class="shadow"  >}}
-
-2. Select the **SERVICES** tab.
-3. Check **Enable SSH**.
-
-{{% alert title="IMPORTANT" color="note" %}}
-
-Be sure that you remember the `hostname`, `username`, and `password` you set, as you will need them when you SSH into your Pi.
-
-Do not use the default username and password on a Raspberry Pi, as this poses a [security risk](https://www.zdnet.com/article/linux-malware-enslaves-raspberry-pi-to-mine-cryptocurrency/).
-
-{{% /alert  %}}
-
-{{% /tab %}}
-{{% tab name="SSH" %}}
-
-To set up SSH authentication:
-
-1. Select the checkbox for **Set username and password** and set a username (for example, your first name) that you will use to log into the Pi.
-   If you skip this step, the default username will be `pi` (not recommended for security reasons).
-   You do not need to specify a password.
-
-   {{< imgproc alt="Raspberry Pi Imager with username specified as 'Robota' and the password field left blank." src="/installation/rpi-setup/imager-set-username.png" resize="500x" declaredimensions=true class="shadow"  >}}
-
-1. Select the **SERVICES** tab.
-1. Check **Enable SSH**.
-1. Select **Allow public-key authentication only**.
-
-   If you select **Allow public-key authentication only**, and the section **Set authorized\_ keys for ''** is pre-populated, that means you have a public SSH key that is ready to use.
-   In that case, you can leave the pre-populated key as-is.
-   If this section is empty, you can either generate a new SSH key using [these instructions](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent), or you can use password authentication instead.
-
-   {{< imgproc alt="Raspberry Pi Imager window showing 'Set Hostname' and 'Enable SSH' both selected." src="/installation/rpi-setup/imager-set-ssh.png" resize="500x" declaredimensions=true class="shadow"  >}}
-
-{{% alert title="IMPORTANT" color="note" %}}
-
-Be sure that you remember the `hostname` and `username` you set, as you will need this when you SSH into your Pi.
-
-{{% /alert  %}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-    Lastly, connect your Pi to Wi-Fi so that you can run `viam-server` wirelessly.
-    Check **Configure wireless LAN** and enter your wireless network credentials.
-    SSID (short for Service Set Identifier) is your Wi-Fi network name, and password is the network password.
-    Change the section `Wireless LAN country` to where your router is currently being operated:
-
-    {{< imgproc alt="Raspberry Pi Imager window showing the 'Configure wireless LAN' option selected with SSID and password information for a wireless network." src="/installation/rpi-setup/imager-set-wifi.png" resize="550x" declaredimensions=true class="shadow"  >}}
-
-    Click **SAVE**.
-
-1.  Double check your OS and Storage settings and then click `YES`:
-
-    {{< imgproc alt="Edit image customization options window" src="/installation/rpi-setup/apply-settings-yes.png" resize="800x" declaredimensions=true class="shadow"  >}}
-
-    You will be prompted to confirm erasing your microSD card: select `YES`.
-
-    {{< imgproc alt="Edit image customization options window" src="/installation/rpi-setup/imager-write-confirm.png" resize="800x" declaredimensions=true class="shadow"  >}}
-
-    You may also be prompted by your operating system to enter an administrator password:
-
-    {{< imgproc alt="macOS admin password confirmation screen." src="/installation/rpi-setup/imager-permission.png" resize="300x" declaredimensions=true class="shadow"  >}}
-
-    After granting permissions to the Imager, it will begin writing and then verifying the Linux installation to the MicroSD card.
-
-    Remove the microSD card from your computer when the installation is complete.
-
-    {{< alert title="Tip: How to think about building a machine" color="tip" >}}
-
-While the Imager is flashing your microSD card, we recommend reading [How to think about building a machine](/operate/hello-world/building/).
-
-    {{< /alert >}}
-
-2.  Place the SD card into your Raspberry Pi and boot the Pi by plugging it in to an outlet.
-    A red LED will turn on to indicate that the Pi is connected to power.
-
-## Next steps
-
-Continue setting up `viam-server` on your Raspberry Pi in [the Viam app](https://app.viam.com/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/prepare/sk-tda4vm.md b/docs/operate/reference/prepare/sk-tda4vm.md
deleted file mode 100644
index b32757615d..0000000000
--- a/docs/operate/reference/prepare/sk-tda4vm.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: "SK-TDA4VM Setup Guide"
-linkTitle: "SK-TDA4VM Setup"
-weight: 25
-type: "docs"
-images: ["/installation/thumbnails/tda4vm.png"]
-imageAlt: "S K - T D A 4 V M"
-description: "Image a Texas Instruments TDA4VM starter kit board to prepare it for viam-server installation."
-no_list: true
-aliases:
-  - /installation/prepare/sk-tda4vm/
-  - /get-started/installation/prepare/sk-tda4vm/
-  - /get-started/prepare/sk-tda4vm/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-## Hardware requirements
-
-- A [Texas Instruments TDA4VM single-board computer](https://www.ti.com/tool/SK-TDA4VM)
-- A USB-C power cable to power the TDA4VM board
-- A microSD card
-- A desktop or laptop computer for flashing the microSD card
-- A way to connect the microSD card to the computer (a microSD slot or microSD reader)
-- An Ethernet cable
-- An HDMI cable
-
-## Required downloads
-
-Download the following files to your computer:
-
-- Download the <a href="https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-SK-TDA4VM" target="_blank">PROCESSOR-SDK-LINUX-SK-TDA4VM — Linux SDK for edge AI applications on TDA4VM Jacinto™ processors</a> image.
-
-- Next, download and install the <a href="https://etcher.balena.io/#download-etcher" target="_blank">Balena Etcher</a> for your desktop/laptop OS.
-  You will use the Balena Etcher to flash the microSD card.
-
-## Flash the image
-
-{{% alert title="Important" color="note" %}}
-You must extract the image from the zip file before flashing the microSD card.
-{{% /alert %}}
-
-{{< imgproc alt="The Balena Etcher interface." src="/installation/sk-tda4vm/etcher.png" resize="600x" declaredimensions=true >}}
-
-<br>
-<br>
-
-1. Insert the microSD card into a reader connected to your computer.
-
-2. Launch Balena Etcher.
-
-3. Click **Flash from File** to open the file selector.
-
-4. Navigate to and select the image you downloaded.
-
-5. Click **Select Target** to choose the storage device corresponding to your microSD card from the selector window.
-
-6. Click on the desired device, then click **Select** to continue.
-
-7. Click **Flash!**.
-   If you receive a warning concerning the size of the microSD card, ensure that you have inserted the proper microSD and also selected the proper device, then click, **Yes, I'm sure** to flash the board.
-   The flashing and verification process may take 10-20 minutes, depending on your system.
-
-   {{< alert title="Tip: How to think about building a machine" color="tip" >}}
-   While the Etcher is flashing your microSD card, we recommend reading [How to think about building a machine](/operate/hello-world/building/).
-   {{< /alert >}}
-
-8. On completion of the flashing and validation process, remove the microSD card from your computer and insert it into the TDA4VM.
-
-{{< imgproc alt="Successful image flash completion screen." src="/installation/sk-tda4vm/completed.png" resize="600x" declaredimensions=true class="shadow"  >}}
-
-## Install Viam dependencies on the TDA4VM
-
-1. Connect the board to Ethernet.
-
-2. Connect the board to a monitor with the HDMI cable.
-
-3. Connect the board to power using the USB-C power cable.
-
-4. Use the credentials and IP address displayed in the upper right-hand corner of the monitor to SSH into the board.
-
-From the SSH session on the TDA4VM board:
-
-1. Clone the TDA4VM repo:
-
-   ```sh {class="command-line" data-prompt="$"}
-   git clone https://github.com/viam-labs/tda4vm-setup.git
-   ```
-
-2. Navigate to the setup directory:
-
-   ```sh {class="command-line" data-prompt="$"}
-   cd tda4vm-setup/
-   ```
-
-3. Make the server setup script executable:
-
-   ```sh {class="command-line" data-prompt="$"}
-   chmod +x tda4vm-viam-setup.sh
-   ```
-
-4. Launch the setup script to install `viam-server` dependencies:
-
-   ```sh {class="command-line" data-prompt="$"}
-   ./tda4vm-viam-setup.sh
-   ```
-
-   Once this process completes, the board will reboot.
-
-## Next steps
-
-You have now installed an operating system on your board.
-To use your board, follow the [setup guide](/operate/install/setup/):
-
-{{< cards >}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
-
-## Need assistance?
-
-{{< snippet "social.md" >}}
diff --git a/docs/operate/reference/services/_index.md b/docs/operate/reference/services/_index.md
deleted file mode 100644
index fde2339e2f..0000000000
--- a/docs/operate/reference/services/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: "Services"
-linkTitle: "Services"
-weight: 30
-type: docs
-layout: "empty"
-canonical: "/operate/reference/services/generic/"
-no_component: true
-empty_node: true
-toc_hide: false
----
diff --git a/docs/operate/reference/services/base-rc/_index.md b/docs/operate/reference/services/base-rc/_index.md
deleted file mode 100644
index 5da5e84b5e..0000000000
--- a/docs/operate/reference/services/base-rc/_index.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: "Base Remote Control Service"
-linkTitle: "Base Remote Control"
-weight: 70
-type: "docs"
-description: "The base remote control service allows you to remotely control a base with an input controller like a gamepad."
-tags: ["base", "services", "rover", "input controller", "remote control"]
-icon: true
-images: ["/services/icons/base-rc.svg"]
-aliases:
-  - "/services/base-rc/"
-  - "/mobility/base-rc/"
-no_service: true
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SME: Eric
----
-
-The base remote control service implements an [input controller](/operate/reference/components/input-controller/) as a remote control for a [base](/operate/reference/components/base/).
-This uses the [`input` API](/operate/reference/components/input-controller/#api) to make it easy to add remote drive controls for your rover or other mobile robot with a controller like a gamepad.
-
-Add the base remote control service after configuring your machine with a base and input controller to control the linear and angular velocity of the base with the controller's button or joystick controls.
-
-Control mode is determined by the configuration attribute `"control_mode"`, for which there are five options:
-
-1. `"arrowControl"`: Arrow buttons control speed and angle
-2. `"triggerSpeedControl"`: Trigger button controls speed and joystick controls angle
-3. `"buttonControl"`: Four buttons (usually X, Y, A, B) control speed and angle
-4. `"joystickControl"`: One joystick controls speed and angle
-5. `"droneControl"`: Two joysticks control speed and angle
-
-You can monitor the input from these controls in the **CONTROL** tab.
-
-## Used with
-
-{{< cards >}}
-{{< relatedcard link="/operate/reference/components/base/" required="yes" >}}
-{{< relatedcard link="/operate/reference/components/input-controller/" required="yes" >}}
-{{< relatedcard link="/operate/reference/components/movement-sensor/" >}}
-{{< /cards >}}
-
-{{% snippet "required-legend.md" %}}
-
-## Configuration
-
-You must configure a [base](/operate/reference/components/base/) with a [movement sensor](/operate/reference/components/movement-sensor/) as part of your machine to be able to use a base remote control service.
-
-First, make sure your base is physically assembled and powered on.
-Then, configure the service:
-
-{{< tabs >}}
-{{% tab name="Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-Select the `base remote control` type.
-Enter a name or use the suggested name for your service and click **Create**.
-
-In your base remote control service's configuration panel, copy and paste the following JSON object into the attributes field:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "base": "<your-base-name>",
-  "input_controller": "<your-controller-name>"
-}
-```
-
-Edit the attributes as applicable to your machine, according to the table below.
-
-For example:
-
-![An example configuration for a base remote control service.](/services/base-rc/base-rc-ui-config.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-base-remote-control-service>",
-  "api": "rdk:service:base_remote_control",
-  "model": "rdk:builtin:builtin",
-  "attributes": {
-    "base": "<your-base-name>",
-    "input_controller": "<your-controller-name>"
-  }
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "gamepad_service",
-  "api": "rdk:service:base_remote_control",
-  "model": "rdk:builtin:builtin",
-  "attributes": {
-    "base": "my-base",
-    "input_controller": "my-input-controller",
-    "control_mode": "arrowControl"
-  }
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Edit and fill in the attributes as applicable.
-The following attributes are available for base remote control services:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `base` | string | **Required** | The `name` of the [base](/operate/reference/components/base/) you have configured for the base you are operating with this service. |
-| `input_controller` | string | **Required** | The `name` of the [input controller](/operate/reference/components/input-controller/) you have configured for the base you are operating with this service. |
-| `control_mode` | string | Optional | The mode of remote control you want to use. <br> Options: <ul><li>`"arrowControl"`</li><li>`"triggerSpeedControl"`</li><li>`"buttonControl"`</li><li>`"joystickControl"`</li> <li>`"droneControl"`</li></ul> <br> Default: `"arrowControl"` |
-| `max_angular_degs_per_sec` | float | Optional | The max angular velocity for the [base](/operate/reference/components/base/) in degrees per second. |
-| `max_linear_mm_per_sec` | float | Optional | The max linear velocity for the [base](/operate/reference/components/base/) in meters per second. |
-
-## API
-
-The base remote control service supports the following methods:
-
-{{< readfile "/static/include/services/apis/generated/base_remote_control-table.md" >}}
-
-{{% alert title="Tip" color="tip" %}}
-
-The following code examples assume that you have a machine configured with a [base](/operate/reference/components/base/) named `"my_base"`, [input controller](/operate/reference/components/input-controller/) named `"my_controller"`, and base remote control service named `"my_base_rc_service"`.
-Make sure to add the required code to connect to your machine and import any required packages at the top of your code file.
-Go to your machine's **CONNECT** tab and select **API keys** to get your credentials, then use the code sample to connect to your machine.
-
-{{% /alert %}}
-
-{{< readfile "/static/include/services/apis/generated/base_remote_control.md" >}}
diff --git a/docs/operate/reference/services/discovery/_index.md b/docs/operate/reference/services/discovery/_index.md
deleted file mode 100644
index 2d37e22b75..0000000000
--- a/docs/operate/reference/services/discovery/_index.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: "Discovery Service"
-linkTitle: "Discovery"
-description: "Use a discovery service to discover available resources on a machine."
-type: docs
-weight: 50
-no_list: true
-#icon: true
-#images: ["/services/icons/discovery.svg"]
-tags: ["discovery", "services"]
-no_service: true
-date: "2025-03-03"
-# updated: ""  # When the content was last entirely checked
-# SMEs: John N.
-modulescript: true
----
-
-A discovery service allows you to return a list of physical hardware available on a machine, and suggest configurations for those components to integrate the hardware into the machine.
-If you are [creating a modular resource](/operate/modules/write-a-driver-module/) that depends on other {{< glossary_tooltip term_id="resource" text="resources" >}} that are discoverable in a systematic way, you can create a discovery service as part of your module to discover those resources.
-
-## Example usage
-
-Imagine you are creating a vision service module that depends on a camera.
-To make it easier for users to configure the camera, you include a discovery service in your module.
-You implement the discovery service to report all the camera paths your computer or SBC finds.
-Users of your module can then:
-
-1. Configure both the vision service and the discovery service in their machine's configuration.
-1. Click the **Test** panel in the discovery service configuration to see all cameras recognized by the machine, presented as a list of configuration snippets.
-1. Create a camera with the copy-pasteable configuration snippet for the camera they want to use, with the camera path already filled in.
-1. Use the configured camera in their vision service configuration.
-
-To see this in action, see [webcam discovery](/operate/reference/components/camera/webcam/#find-a-video-path-using-a-discovery-service) as an example.
-
-To interact with a discovery service programmatically, use the [discovery service API](/reference/apis/services/discovery/).
-
-## Configuration
-
-To use a discovery service, you need to add it to your machine's configuration.
-
-Go to your machine's **CONFIGURE** page, and add your discovery service.
-
-The following list shows the available discovery service models.
-For additional configuration information, click on the model name:
-
-{{< tabs >}}
-{{% tab name="viam-server" %}}
-
-{{<resources api="rdk:service:discovery" type="discovery" no-intro="true">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-{{% /tab %}}
-{{% tab name="Micro-RDK" %}}
-
-{{< alert title="Support Notice" color="note" >}}
-
-There is currently no support for this component compatible with the Micro-RDK.
-
-{{< /alert >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [discovery service API](/reference/apis/services/discovery/) supports the following methods:
-
-{{< readfile "/static/include/services/apis/generated/discovery-table.md" >}}
diff --git a/docs/operate/reference/services/frame-system/_index.md b/docs/operate/reference/services/frame-system/_index.md
deleted file mode 100644
index a7acd8bce6..0000000000
--- a/docs/operate/reference/services/frame-system/_index.md
+++ /dev/null
@@ -1,212 +0,0 @@
----
-title: "The frame system"
-linkTitle: "Frame system"
-description: "The frame system holds reference frame information for the relative position of components in space."
-type: docs
-weight: 50
-no_list: true
-icon: true
-images: ["/services/icons/frame-system.svg"]
-tags: ["frame system", "services"]
-aliases:
-  - /services/frame-system/
-  - /mobility/frame-system/
-  - /services/frame-system/frame-config/
-  - /mobility/frame-system/frame-config/
-  - /operate/reference/services/frame-system/frame-config/
-no_service: true
-date: "2022-01-01"
-updated: "2024-10-18"
-# SMEs: Peter L, Gautham, Bijan
----
-
-The frame system is the basis for some of Viam's other services, like [motion](/operate/reference/services/motion/) and [vision](/reference/services/vision/).
-It stores the required contextual information to use the position and orientation readings returned by some components.
-
-It is a mostly static system for storing the "reference frame" of each component of a machine within a coordinate system configured by the user.
-
-## Used with
-
-{{< cards >}}
-{{< relatedcard link="/operate/reference/components/arm">}}
-{{< relatedcard link="/operate/reference/components/base/">}}
-{{< relatedcard link="/operate/reference/components/camera/">}}
-{{< relatedcard link="/operate/reference/components/gantry/">}}
-{{< relatedcard link="/operate/reference/components/gripper/">}}
-{{< /cards >}}
-
-## Configuration
-
-For a full how-to guide, see [Frame system](/motion-planning/frame-system/) and the [frame system how-tos](/motion-planning/frame-system/).
-
-You can configure a reference frame within the frame system for each of your machine's components:
-
-1. Navigate to the **CONFIGURE** tab of your machine's page.
-
-1. Find the configuration card for the component you want to add a frame to.
-
-1. Click the **Frame** button.
-
-1. Leave the default values, or edit the frame configuration.
-   The frame configuration is a JSON object with the following parameters:
-
-<!-- prettier-ignore -->
-| Parameter | Required? | Description |
-| --------- | ----------- | ----- |
-| `parent`  | **Required** | The name of the reference frame you want to act as the parent of this frame. <br> Default: `world`. |
-| `translation` | **Required** | The coordinates that the origin of this component's reference frame has within its parent reference frame. <br> Units: Millimeters. <br> Default: `(0, 0, 0)`. |
-| `orientation`  | **Required** | The [orientation vector](/motion-planning/reference/orientation-vectors/) that yields the axes of the component's reference frame when applied as a rotation to the axes of the parent reference frame. <br> Types: Orientation vector in degrees (`ov_degrees`), orientation vector in radians (`ov_radians`), Euler angles (`euler_angles`), and quaternion (`quaternion`). <br> Default: `(0, 0, 1), 0`. |
-| `geometry`  | Optional | Collision geometries for defining bounds in the environment of the machine. <br> Units: Millimeters. <br> Types: `sphere`, `box`, and `capsule`. <br> Default: `none`. |
-
-{{< tabs >}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "<your_component_name_1>",
-      "type": "<your_component_type_1>",
-      "model": "<your_component_model_1>",
-      "attributes": { ... },
-      "depends_on": [],
-      "frame": {
-        "parent": "<world_or_parent_component_name>",
-        "translation": {
-          "y": <float>,
-          "z": <float>,
-          "x": <float>
-        },
-        "orientation": {
-          "type": "<type>",
-          "value": {
-            "x": <float>,
-            "y": <float>,
-            "z": <float>,
-            "th": <float> // "w": <int> if "type": "quaternion"
-          }
-        },
-        "geometry": {
-          "type": "<type>",
-          "x": <float>,
-          "y": <float>,
-          "z": <float>
-        }
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "components": [
-    {
-      "name": "cam",
-      "api": "rdk:component:camera",
-      "model": "webcam",
-      "attributes": {
-        "video_path": "FDF90FEC-59E5-4FCF-AABD-DA03C4E19BFB"
-      },
-      "frame": {
-        "parent": "world",
-        "translation": {
-          "x": 0,
-          "y": 0,
-          "z": 0
-        },
-        "orientation": {
-          "type": "quaternion",
-          "value": {
-            "x": 0,
-            "y": 0,
-            "z": 0,
-            "w": 1
-          }
-        },
-        "geometry": {
-          "type": "box",
-          "x": 100,
-          "y": 100,
-          "z": 100
-        }
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% alert title="Info" color="info" %}}
-
-The `orientation` parameter offers different types for ease of configuration, but the frame system always stores and returns [orientation vectors](/motion-planning/reference/orientation-vectors/) in radians.
-Other types will be converted to `ov_radians`.
-
-{{% /alert %}}
-
-{{% alert title="Tip" color="tip" %}}
-
-For [base components](/operate/reference/components/base/), Viam considers `+X` to be to the right, `+Y` to be forwards, and `+Z` to be up.
-You can use [the right-hand rule](https://en.wikipedia.org/wiki/Right-hand_rule) to understand rotation about any of these axes.
-
-For non base components, there is no inherent concept of "forward," so it is up to the user to define frames that make sense in their application.
-
-{{% /alert %}}
-
-## How the frame system works
-
-`viam-server` builds a tree of reference frames for your machine with the `world` as the root node and regenerates this tree following reconfiguration.
-
-Access a [topologically-sorted list](https://en.wikipedia.org/wiki/Topological_sorting) of the generated reference frames in the machine's logs at `--debug` level:
-
-![an example of a logged frame system](/services/frame-system/frame_sys_log_example.png)
-
-Consider the example of nested reference frame configuration where two dynamic components are attached: A robotic arm, `A`, attaches to a gantry, `G`, which in turn is fixed in place at a point in the `world` frame of a table.
-
-The resulting tree of reference frames looks like:
-
-{{<imgproc src="/services/frame-system/frame_tree.png" resize="x1100" declaredimensions=true alt="Linear tree diagram of nested reference frames with world at the root, connected to G_origin, which connects to G, in turn connected to A_origin, connected to A." style="max-width:500px" class="imgzoom" >}}
-
-`viam-server` builds the connections in this tree by looking at the `"frame"` portion of each component in the machine's configuration and defining _two_ reference frames for each component:
-
-1. One with the name of the component, representing the actuator or final link in the component's kinematic chain: like `"A"` as the end of an arm.
-2. Another representing the origin of the component, defined with the component's name and the suffix _"\_origin"_.
-
-## Access the frame system
-
-The [Machine Management API](/reference/apis/robot/) supplies the following methods to interact with the frame system:
-
-<!-- prettier-ignore -->
-| Method Name | Description |
-| ----- | ----------- |
-| [`FrameSystemConfig`](/reference/apis/robot/#framesystemconfig) | Return a topologically sorted list of all the reference frames monitored by the frame system. |
-| [`TransformPose`](/reference/apis/robot/#transformpose) | Transform a given source Pose from the original reference frame to a new destination reference frame. |
-
-## Additional transforms
-
-_Additional transforms_ exist to help the frame system determine the location of and relationships between objects not initially known to the machine.
-
-### Example of additional transforms
-
-Imagine you are using a wall-mounted [camera](/operate/reference/components/camera/) to find objects near your arm.
-You can use the [vision service](/reference/services/vision/) with the camera to detect objects and provide the poses of the objects with respect to the camera's reference frame.
-The camera is fixed with respect to the `world` reference frame.
-
-If the camera finds an apple or an orange, you can command the arm to move to the detected fruit's location by providing an additional transform that contains the detected pose of the fruit with respect to the camera that performed the detection.
-
-The frame system uses the supplemental transform to determine where the arm should move to pick up the fruit.
-
-### Transform usage
-
-- You can pass a detected object's frame information to the `supplemental_transforms` parameter in your calls to Viam's motion service's [`GetPose`](/reference/apis/services/motion/#getpose) method.
-- Functions of some services and components also take in a `WorldState` parameter, which includes a `transforms` property.
-- [`TransformPose`](/reference/apis/robot/#transformpose) has the option to take in these additional transforms.
-
-### Visualize components and frames
-
-{{< readfile "/static/include/snippet/visualize.md" >}}
diff --git a/docs/operate/reference/services/generic/_index.md b/docs/operate/reference/services/generic/_index.md
deleted file mode 100644
index 1f15466d65..0000000000
--- a/docs/operate/reference/services/generic/_index.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: "Generic Service"
-linkTitle: "Generic Service"
-childTitleEndOverwrite: "Generic Service"
-weight: 500
-type: "docs"
-description: "A service that does not fit any of the other APIs."
-tags: ["generic", "services"]
-icon: true
-images: ["/icons/components/generic.svg"]
-no_list: true
-modulescript: true
-hide_children: true
-aliases:
-  - /registry/advanced/generic/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs:
----
-
-The _generic_ service API enables you to add support for unique types of services that do not already have an [appropriate API](/reference/apis/#service-apis) defined for them.
-
-For example, when writing code to manage [simultaneous localization and mapping (SLAM)](/operate/reference/services/slam/) for your machine, it makes sense to use the existing [SLAM API](/reference/apis/services/slam/#api), which provides specific functionality required for generating accurate maps of an environment.
-However, if you want to create a new service to monitor your machine's CPU and RAM usage for example, you need very different functionality that isn't currently exposed in any API.
-Instead, you can use the generic service API to add support for your unique type of service, like local system monitoring, to your machine.
-
-Use generic for a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}} model that represents a unique type of service.
-If you are adding support for unique or proprietary hardware, rather than adding new high-level software functionality, use the [generic component](/operate/reference/components/generic/) instead.
-
-There are no built-in generic service models (other than `fake`).
-
-{{% alert title="Important" color="note" %}}
-
-The generic service API only supports the `DoCommand` method.
-If you use the generic API, your module needs to define any and all service functionality and pass it through `DoCommand`.
-
-Whenever possible, it is best to use an [existing service API](/reference/apis/services/) instead of generic so that you do not have to replicate code.
-If you want to use most of an existing API but need just a few other functions, try using the `DoCommand` endpoint and extra parameters to add custom functionality to an existing API, instead of using the generic service.
-
-{{% /alert %}}
-
-## Configuration
-
-{{<resources_svc api="rdk:service:generic" type="generic">}}
-
-{{< readfile "/static/include/create-your-own-mr.md" >}}
-
-## API
-
-The [generic service API](/reference/apis/services/generic/) supports the following method:
-
-{{< readfile "/static/include/services/apis/generated/generic_service-table.md" >}}
-
-## Troubleshooting
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
-
-{{< snippet "social.md" >}}
diff --git a/docs/operate/reference/services/generic/fake.md b/docs/operate/reference/services/generic/fake.md
deleted file mode 100644
index 8ee3943afc..0000000000
--- a/docs/operate/reference/services/generic/fake.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: "Configure a Fake Generic Service"
-linkTitle: "fake"
-weight: 10
-type: "docs"
-description: "Configure a fake generic service using the generic service API."
-service_description: "A model used for testing a generic service."
-tags: ["generic", "services"]
-aliases:
-  - /registry/advanced/generic/fake/
-  - /services/generic/fake/
-toc_hide: true
----
-
-Configure a `fake` generic service to test implementing a generic service on your machine:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** button and select **Component or service**.
-Select the `generic` type, then select the `fake` model.
-Enter a name or use the suggested name for your generic service and click **Create**.
-
-![An example configuration for a fake generic service.](/services/fake-generic-service-config.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "<your-fake-generic-service-name>",
-  "model": "fake",
-  "api": "rdk:component:generic",
-  "attributes": {}
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-No attributes are available for the `fake` generic service.
-See [GitHub](https://github.com/viamrobotics/rdk/blob/main/services/generic/fake/generic.go) for API call return specifications.
diff --git a/docs/operate/reference/services/motion/_index.md b/docs/operate/reference/services/motion/_index.md
deleted file mode 100644
index a4455dfa21..0000000000
--- a/docs/operate/reference/services/motion/_index.md
+++ /dev/null
@@ -1,187 +0,0 @@
----
-title: "Motion Service"
-linkTitle: "Motion"
-weight: 40
-type: "docs"
-description: "The motion service enables your machine to plan and move its components relative to itself, other machines, and the world."
-tags: ["motion", "motion planning", "services"]
-icon: true
-images: ["/services/icons/motion.svg"]
-no_list: true
-aliases:
-  - "/services/motion/"
-  - "/mobility/motion/"
-no_service: true
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SME: Motion team
----
-
-The motion service enables your machine to plan and move itself or its components relative to itself, other machines, and the world.
-The motion service:
-
-1. Gathers the current positions of the machine’s components as defined with the [frame system](/operate/reference/services/frame-system/).
-2. Plans the necessary motions to move a component to a given destination while obeying any [constraints you configure](constraints/).
-
-The motion service can:
-
-- use motion [planning algorithms](algorithms/) locally on your machine to plan coordinated motion across many components.
-- pass movement requests through to individual components which have implemented their own motion planning.
-
-## Configuration
-
-You need to configure frames for your machine's components with the [frame system](/operate/reference/services/frame-system/).
-This defines the spatial context within which the motion service operates.
-
-The motion service itself is enabled on the machine by default, so you do not need to add any extra configuration to enable it.
-
-## Access the motion service in your code
-
-Use the motion service in your code by creating a motion service client and then calling its methods.
-As with other resource clients, how you get the client depends on whether your code is part of a client application or a module:
-
-{{< tabs >}}
-{{% tab name="From a client application" %}}
-
-To access a motion service, use its name from the machine configuration.
-To access the motion service built into `viam-server` from your client application code, use the resource name `builtin` to get a motion service client:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python {class="line-numbers linkable-line-numbers"}
-# Get a motion service client
-motion_service = MotionClient.from_robot(machine, "builtin")
-
-# Then use the motion service, for example:
-moved = await motion_service.move(gripper_name, destination, world_state)
-```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go {class="line-numbers linkable-line-numbers"}
-// Get a motion service client
-motionService, err := motion.FromProvider(machine, "builtin")
-if err != nil {
-  logger.Fatal(err)
-}
-
-// Then use the motion service, for example:
-moved, err := motionService.Move(context.Background(), motion.MoveReq{
-  ComponentName: gripperName,
-  Destination: destination,
-  WorldState: worldState
-})
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="From within a module" %}}
-
-To access a motion service, use its name from the machine configuration.
-To access the motion service built into `viam-server` from your module code, you need to add the motion service as a [module dependency](/operate/modules/advanced/dependencies/), using the resource name `builtin`.
-For example:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-1. Edit your `validate_config` function to add the `builtin` motion service as a dependency so that it is available to your module.
-   You do not need to check for it in your config because the built-in motion service is always enabled.
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   @classmethod
-   def validate_config(
-       cls, config: ComponentConfig
-   ) -> Tuple[Sequence[str], Sequence[str]]:
-       req_deps = []
-       req_deps.append("builtin")
-       return req_deps, []
-   ```
-
-1. Edit your `reconfigure` function to add the motion service as an instance variable so that you can use it in your module:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   def reconfigure(
-       self, config: ComponentConfig, dependencies: Mapping[ResourceName, ResourceBase]
-   ):
-       motion_resource = dependencies[Motion.get_resource_name("builtin")]
-       self.motion_service = cast(MotionClient, motion_resource)
-
-       return super().reconfigure(config, dependencies)
-   ```
-
-1. You can now use the motion service in your module, for example:
-
-   ```python {class="line-numbers linkable-line-numbers"}
-   def move_around_in_some_way(self):
-       moved = await self.motion_service.move(gripper_name, destination, world_state)
-       return moved
-   ```
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-The following example assumes your module uses `AlwaysRebuild` and does not have a `Reconfigure` function defined.
-
-```go {class="line-numbers linkable-line-numbers"}
-// Return the motion service as a dependency
-func (cfg *Config) Validate(path string) ([]string, []string, error) {
-  deps := []string{motion.Named("builtin").String()}
-  return deps, nil, nil
-}
-
-// Then use the motion service, for example:
-func (c *Component) MoveAroundInSomeWay() error {
-  c.Motion, err = motion.FromDependencies(deps, "builtin")
-  if err != nil {
-    return nil, err
-  }
-  moved, err := c.Motion.Move(context.Background(), motion.MoveReq{
-    ComponentName: gripperName,
-    Destination: destination,
-    WorldState: worldState
-  })
-  return moved, err
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-If you created your own custom motion service, you can access it using the resource name you gave it in your machine's configuration.
-You'll also need to check for it in your validate function, since it is not built into `viam-server`.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## API
-
-The [motion service API](/reference/apis/services/motion/) supports the following methods:
-
-{{< readfile "/static/include/services/apis/generated/motion-table.md" >}}
-
-## Test the motion service
-
-You can test motion on your machine from the [**CONTROL** tab](/manage/troubleshoot/teleoperate/default-interface/).
-
-![Motion card on the Control tab](/services/motion/motion-rc-card.png)
-
-Enter x and y coordinates to move your machine to, then click the **Move** button to issue a `MoveOnMap()` request.
-
-{{< alert title="Info" color="info" >}}
-
-The `plan_deviation_m` for `MoveOnMap()` on calls issued from the **CONTROL** tab is 0.5 m.
-
-{{< /alert >}}
-
-## Next steps
-
-The following tutorials contain complete example code for interacting with a robot arm through the arm component API, and with the motion service API, respectively:
-
-{{< cards >}}
-{{% card link="/motion-planning/move-an-arm/move-to-pose/" %}}
-{{% card link="/tutorials/services/plan-motion-with-arm-gripper" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/services/motion/algorithms.md b/docs/operate/reference/services/motion/algorithms.md
deleted file mode 100644
index 4948562879..0000000000
--- a/docs/operate/reference/services/motion/algorithms.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: "About the Motion Planning Algorithms"
-linkTitle: "Algorithms"
-weight: 20
-type: "docs"
-description: "Information about the motion planning algorithms Viam uses."
-aliases:
-  - "/services/motion/algorithms/"
-  - "/mobility/motion/algorithms/"
-no_service: true
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-Robotic motion planning is heavily reliant on planning algorithms to determine how to achieve motion for a particular scenario.
-Many algorithms already exist for this problem, and motion planning is a domain where improvements and novel developments occur frequently.
-Viam does not implement all motion planning algorithms but has implemented a few in its strategy for planning general robot motion.
-The algorithms Viam supports are all based in principle on [RRT](https://en.wikipedia.org/wiki/Rapidly-exploring_random_tree):
-
-The algorithms that Viam uses for motion planning depend on the type of the robot in question; planning for "Kinematic Chains", consisting of Gantry and Arm components is treated differently than planning for Base components
-
-## Kinematic Chains
-
-### RRT\*-Connect
-
-RRT\*-Connect is an asymptotically optimal planner that samples the planning space randomly, connecting viable paths as it finds them.
-It continues sampling after it finds its first valid path, and if it finds future paths that are more efficient, it updates to report those instead.
-For Viam, efficiency/path quality is measured in terms of total kinematics state excursion.
-For an arm, the sum of all joint changes is minimized.
-For a gantry, the sum of all linear movement is minimized.
-This algorithm can route around obstacles, but cannot satisfy topological constraints.
-
-### CBiRRT
-
-CBiRRT stands for Constrained, Bi-directional implementation of [RRT](https://en.wikipedia.org/wiki/Rapidly-exploring_random_tree).
-It creates paths which conform to specified constraints, and attempts to smooth them afterwards as needed.
-By default, it does not constrain the path of motion at all.
-This is to ensure that paths will be found when using defaults.
-CBiRRT returns the first valid path that it finds.
-The CBiRRT algorithm Viam uses is based on the algorithm described in the paper [Manipulation Planning on Constraint Manifolds](https://www.ri.cmu.edu/pub_files/2009/5/berenson_dmitry_2009_2.pdf)
-
-### How the motion service applies these algorithms
-
-By default, Viam's motion planning library uses a hybrid approach:
-
-First, Viam runs RRT*-Connect for 1.5 seconds.
-If RRT*-Connect does not return a path, then Viam calls CBiRRT to attempt to find a path.
-CBiRRT takes a more incremental approach which often performs better in difficult, constrained scenarios.
-If CBiRRT is successful, it returns a path.
-If unsuccessful, CBiRRT returns an error.
-However, if RRT*-Connect is initially successful, Viam evaluates the path for optimality.
-If the total amount of joint excursion is more than double the minimum possible to go directly to the best Inverse Kinematics solution, then Viam runs CBiRRT to attempt to get a better path than what RRT*-Connect was able to create.
-Viam smooths the two paths, then compares them to one another, and returns the most optimal path.
-
-## Bases
-
-### TP-Space-RRT
-
-This algorithm is based on the research described in the paper: [TP-Space RRT - Kinematic Path Planning of Non-Holonomic Any-Shape Vehicles](https://www.researchgate.net/publication/275584014_TP-Space_RRT_-_Kinematic_Path_Planning_of_Non-Holonomic_Any-Shape_Vehicles). This algorithm is suitable to planning for Bases since it is able to incorporate non-holonomic constraints into the planner directly to only return plans that are kinematically feasible for the base. One such example of a constraint that this allows us to impose is a minimum turning radius constraint, which is expressed through the [Base's](/operate/reference/components/base/) [GetProperties](https://docs.viam.com/components/base/#getproperties) method.
-
-This algorithm works by exploring a series of continuous trajectory-parameter spaces (TP-space) which describe different actions the base can take, such as, for example, turn and then go straight.
-This concept is then used within an RRT framework to compose these different actions into a series of sequential actions to be taken in order to navigate the base to its goal.
diff --git a/docs/operate/reference/services/motion/constraints.md b/docs/operate/reference/services/motion/constraints.md
deleted file mode 100644
index b4d92d07ed..0000000000
--- a/docs/operate/reference/services/motion/constraints.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-title: "Configure Motion Constraints"
-linkTitle: "Constraints"
-weight: 10
-type: "docs"
-description: "Configure constraints to specify certain types of motion."
-aliases:
-  - "/services/motion/constraints/"
-  - "/mobility/motion/constraints/"
-no_service: true
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-You can constrain the motion of your machine using the motion service's built-in constraint options.
-Constraints are passed as arguments to the [`Move`](/reference/apis/services/motion/#move) method.
-
-The following constraints are available:
-
-- [Linear constraint](#linear-constraint)
-- [Orientation constraint](#orientation-constraint)
-- [Next steps](#next-steps)
-
-## Linear constraint
-
-The linear constraint (`{"motion_profile": "linear"}`) forces the path taken by `component_name` to follow an exact linear path from the start to the goal.
-If the start and goal orientations are different, the orientation along the path will follow the quaternion [Slerp (Spherical Linear Interpolation)](https://en.wikipedia.org/wiki/Slerp) of the orientation from start to goal.
-This has the following sub-options:
-
-<!-- prettier-ignore -->
-| Parameter Name | Type | Default | Description |
-| -------------- | ---- | ------- | ----------- |
-| line_tolerance_mm | float | 0.1 | Max linear deviation from straight-line between start and goal, in mm. |
-| orientation_tolerance_degs | float | 2.0 | Allowable deviation from Slerp between start/goal orientations, in degrees. |
-
-**Example usage**:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python {class="line-numbers linkable-line-numbers"}
-# Move a gripper with a linear constraint
-moved = await motion.move(
-    component_name=my_gripper,
-    destination=PoseInFrame(
-        reference_frame="my_frame",
-        pose=goal_pose),
-    world_state=worldState,
-    constraints={
-        Constraints(
-            linear_constraint=[LinearConstraint(line_tolerance_mm=0.2)])
-    },
-    extra={})
-```
-
-You can find more information in the [Python SDK Docs](https://python.viam.dev/autoapi/viam/gen/service/motion/v1/motion_pb2/index.html#viam.gen.service.motion.v1.motion_pb2.Constraints).
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go {class="line-numbers linkable-line-numbers"}
-// Move a gripper with a linear constraint
-myConstraints := &servicepb.Constraints{LinearConstraint: []*servicepb.LinearConstraint{&servicepb.LinearConstraint{}}}
-
-moved := motionService.Move(
-    context.Background(),
-    myGripperResourceName,
-    NewPoseInFrame("myFrame", myGoalPose),
-    worldState,
-    myConstraints,
-    nil
-    )
-```
-
-You can find more information in the [Go SDK Docs](https://pkg.go.dev/go.viam.com/api/service/motion/v1#Constraints).
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Orientation constraint
-
-The orientation constraint (`{"motion_profile": "orientation"}`) places a restriction on the orientation change during a motion, such that the orientation during the motion does not deviate from the [Slerp](https://en.wikipedia.org/wiki/Slerp) between start and goal by more than a set amount.
-This is similar to the "orient_tolerance" option in the linear profile, but without any path restrictions.
-If set to zero, a movement with identical starting and ending orientations will hold that orientation throughout the movement.
-
-<!-- prettier-ignore -->
-| Parameter Name | Type | Default | Description |
-| -------------- | ---- | ------- | ----------- |
-| orientation_tolerance_degs | float | 2.0 | Allowable deviation from Slerp between start/goal orientations, in degrees. |
-
-**Example usage**:
-
-{{< tabs >}}
-{{% tab name="Python" %}}
-
-```python {class="line-numbers linkable-line-numbers"}
-# Move a gripper with an orientation constraint
-moved = await motion.move(
-    component_name=my_gripper,
-    destination=PoseInFrame(
-        reference_frame="my_frame",
-        pose=goal_pose),
-    world_state=worldState,
-    constraints=Constraints(orientation_constraint=[OrientationConstraint()]),
-    extra={})
-```
-
-You can find more information in the [Python SDK Docs](https://python.viam.dev/autoapi/viam/gen/service/motion/v1/motion_pb2/index.html#viam.gen.service.motion.v1.motion_pb2.Constraints).
-
-{{% /tab %}}
-{{% tab name="Go" %}}
-
-```go {class="line-numbers linkable-line-numbers"}
-// Move a gripper with an orientation constraint
-myConstraints := &servicepb.Constraints{OrientationConstraint: []*servicepb.OrientationConstraint{&servicepb.OrientationConstraint{}}}
-
-moved := motionService.Move(
-    context.Background(),
-    myGripperResourceName,
-    NewPoseInFrame("myFrame", myGoalPose),
-    worldState,
-    myConstraints,
-    nil
-    )
-```
-
-You can find more information in the [Go SDK Docs](https://pkg.go.dev/go.viam.com/api/service/motion/v1#Constraints).
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Next steps
-
-Constraints are used in the following tutorials:
-
-{{< cards >}}
-{{% card link="/tutorials/projects/claw-game/" %}}
-{{% card link="/tutorials/services/constrain-motion/" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/services/navigation/_index.md b/docs/operate/reference/services/navigation/_index.md
deleted file mode 100644
index 4e50d2a442..0000000000
--- a/docs/operate/reference/services/navigation/_index.md
+++ /dev/null
@@ -1,387 +0,0 @@
----
-title: "Navigation Service"
-linkTitle: "Navigation"
-description: "The navigation service uses GPS to autonomously navigate a rover to user-defined waypoints."
-type: docs
-weight: 50
-no_list: true
-icon: true
-images: ["/services/icons/navigation.svg"]
-tags: ["navigation", "services", "base", "rover"]
-aliases:
-  - "/services/navigation/"
-  - "/mobility/navigation/"
-no_service: true
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: Raymond
----
-
-The navigation service is the stateful definition of Viam's [motion service](/operate/reference/services/motion/).
-It uses GPS to autonomously navigate a rover [base](/operate/reference/components/base/) to user-defined waypoints.
-
-Configure your base with a navigation service, add waypoints, and set the mode of the service to [**Waypoint**](/reference/apis/services/navigation/#setmode) to move your rover along a defined path at your desired motion configuration.
-
-## Requirements
-
-You must configure a [base](/operate/reference/components/base/) with [movement sensors](/operate/reference/components/movement-sensor/) as part of your machine to configure a navigation service.
-
-To use the navigation service, configure a stack of movement sensors that implement the following methods in their {{< glossary_tooltip term_id="model" text="models'" >}} implementations of the [movement sensor API](/reference/apis/components/movement-sensor/#api):
-
-- [`GetPosition()`](/reference/apis/components/movement-sensor/#getposition)
-- [`GetCompassHeading()`](/reference/apis/components/movement-sensor/#getcompassheading)
-- [`GetProperties()`](/reference/apis/components/movement-sensor/#getproperties)
-
-The base should implement the following:
-
-- [`SetVelocity()`](/reference/apis/components/base/#setvelocity)
-- [`GetGeometries()`](/reference/apis/components/base/#getgeometries)
-- [`GetProperties()`](/reference/apis/components/base/#getproperties)
-
-See [navigation concepts](#navigation-concepts) for more info on how to implement and use movement sensors taking these measurements.
-
-## Configuration
-
-First, make sure your base is physically assembled and powered on.
-Then, configure the service:
-
-{{< tabs >}}
-{{% tab name="Config Builder" %}}
-
-Navigate to the **CONFIGURE** tab of your machine's page.
-Click the **+** icon next to your machine part in the left-hand menu and select **Configuration block**.
-Select the `navigation` type.
-Enter a name or use the suggested name for your service and click **Create**.
-
-{{<imgproc src="/services/navigation/navigation-ui-config.png" resize="1200x" style="width: 900px" alt="An example configuration for a navigation service.">}}
-
-Edit the attributes as applicable to your machine, according to the table below.
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-"services": [
-{
-  "name": "your-navigation-service",
-  "api": "rdk:service:navigation",
-  "model": "rdk:builtin:builtin",
-  "attributes": {
-    "store": {
-      "type": "<your-store-type>"
-    },
-    "movement_sensor": "<your-movement-sensor>",
-    "base": "<your-base>",
-    "obstacle_detectors": [
-      {
-        "vision_service": "<your-vision-service>",
-        "camera": "<your-camera>"
-      }
-    ]
-  }
-}
-    ... // Other services
-]
-```
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "name": "test_navigation",
-  "api": "rdk:service:navigation",
-  "model": "rdk:builtin:builtin",
-  "attributes": {
-    "store": {
-      "type": "mongodb",
-      // Remove "config": { ... } below if using "type": "memory"
-      "config": {
-        "uri": "mongodb://127.0.0.1:12345"
-      }
-    }
-  },
-  "movement_sensor": "your-movement-sensor",
-  "obstacle_detectors": [
-    {
-      "vision_service": "your-vision-service",
-      "camera": "your-camera"
-    },
-    {
-      "vision_service": "your-vision-service-2",
-      "camera": "your-camera-2"
-    }
-  ]
-  "base": "your-base",
-  "obstacles": [
-    {
-      "geometries": [
-        {
-          "label": "your-label-for-this-obstacle",
-          "orientation": {
-            "type": "ov_degrees",
-            "value": {
-              "x": 1,
-              "y": 0,
-              "z": 0,
-              "th": 90
-            }
-          },
-          "x": 10,
-          "y": 10,
-          "z": 10
-        }
-      ],
-      "location": {
-        "latitude": 1,
-        "longitude": 1
-      }
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Edit and fill in the attributes as applicable.
-The following attributes are available for `Navigation` services:
-
-<!-- prettier-ignore -->
-| Name | Type | Required? | Description |
-| ---- | ---- | --------- | ----------- |
-| `store` | obj | **Required** | The type and configuration of data storage to use. Either type `"memory"`, where no additional configuration is needed and the waypoints are stored in local memory while the navigation process is running, or `"mongodb"`, where data persists at the specified [MongoDB URI](https://www.mongodb.com/docs/manual/reference/connection-string) of your MongoDB deployment. <br> Default: `"memory"` |
-| `base` | string | **Required** | The `name` you have configured for the [base](/operate/reference/components/base/) you are operating with this service. |
-| `movement_sensor` | string | **Required** | The `name` of the [movement sensor](/operate/reference/components/movement-sensor/) you have configured for the base you are operating with this service. |
-| `motion_service` | string | Optional | The `name` of the [motion service](/operate/reference/services/motion/) you have configured for the base you are operating with this service. If you have not added a motion service to your machine, the default motion service will be used. Reference this default service in your code with the name `"builtin"`. |
-| `obstacle_detectors` | array | Optional | An array containing objects with the `name` of each [`"camera"`](/operate/reference/components/camera/) you have configured for the base you are navigating, along with the `name` of the [`"vision_service"`](/operate/reference/services/motion/) you are using to detect obstacles. Note that any vision services on remote parts will only be able to access cameras on the same remote part. |
-| `position_polling_frequency_hz` | float | Optional | The frequency in Hz to poll for the position of the machine. <br> Default: `1` |
-| `obstacle_polling_frequency_hz` | float | Optional | The frequency in Hz to poll each vision service for new obstacles. <br> Default: `1` |
-| `plan_deviation_m` | float | Optional | The distance in meters that a machine is allowed to deviate from the motion plan. <br> Default: `2.6`|
-| `degs_per_sec` | float | Optional | The default angular velocity for the [base](/operate/reference/components/base/) in degrees per second. <br> Default: `20` |
-| `meters_per_sec` | float | Optional | The default linear velocity for the [base](/operate/reference/components/base/) in meters per second. <br> Default: `0.3` |
-| `obstacles` | obj | Optional | Any obstacles you wish to add to the machine's path. See the [motion service](/operate/reference/services/motion/) for more information. |
-| `bounding_regions` | obj | Optional | Set of bounds which the robot must remain within while navigating. See the [motion service](/operate/reference/services/motion/) for more information. |
-
-### Configure and calibrate the frame system service for GPS navigation
-
-{{% alert title="Info" color="info" %}}
-
-The [frame system service](/operate/reference/services/frame-system/) is an internally managed and mostly static system for storing the reference frame of each component of a machine within a coordinate system configured by the user.
-
-It stores the required contextual information for Viam's services like [Motion](/operate/reference/services/motion/) and [Vision](/reference/services/vision/) to use the position and orientation readings returned by components like [movement sensors](/operate/reference/components/movement-sensor/).
-
-{{% /alert %}}
-
-To make sure your rover base's autonomous GPS navigation with the navigation service is accurate, configure and calibrate the frame system service for the components of your machine.
-
-#### Configure
-
-Add [reference frames](/operate/reference/services/frame-system/#configuration) to your rover [base](/operate/reference/components/base/) and [movement sensor](/operate/reference/components/movement-sensor/) configurations:
-
-- Navigate to the **CONFIGURE** tab of your machine's page.
-- Find your base configuration card and click the **Frame** button.
-- Since you haven't adjusted any parameters yet, the default reference frame will be shown for your base:
-
-  {{<imgproc src="/services/navigation/select-base-frame.png" resize="700x" style="width: 300px" alt="Frame card for a base with the default reference frame settings">}}
-
-- Keep the `parent` frame as `world`.
-- Configure a `geometry` for the base that reflects its physical dimensions.
-  Measure the physical dimensions of your base and use them to configure the size of your geometry.
-  Units are in _mm_.
-
-  For example, you would configure a box-shaped base with dimensions of 100mm x 100mm x 100mm (l x h x w) as follows:
-
-  {{<imgproc src="/services/navigation/configure-base-geometry.png" resize="700x" style="width: 300px" alt="The frame card for the base.">}}
-
-- Add a frame to your movement sensor configuration by clicking the **Frame** button.
-- Set the `parent` within the frame card to the name of your base.
-- Give the movement sensor a `translation` that reflects where it is mounted on your base, measuring the coordinates with respect to the origin of the base.
-  In other words, designate the base origin as `(0,0,0)` and measure the distance between that and the origin of the sensor to obtain the coordinates.
-
-  For example, you would configure a movement sensor mounted 200mm on top of your base as follows:
-
-  {{<imgproc src="/services/navigation/full-frame-movement-sensor-ui.png" resize="700x" style="width: 300px" alt="The frame card for the movement sensor.">}}
-
-You can also adjust the `orientation` and `geometry` of your movement sensor or base, if necessary.
-See [the frame system service](/operate/reference/services/frame-system/) for instructions.
-
-#### Calibrate
-
-Then, to calibrate your frame system for the most accurate autonomous GPS navigation with the navigation service:
-
-- After configuring your machine, navigate to the **CONTROL** tab and select the card matching the name of your movement sensor.
-- Monitor the readings displayed on the card, and verify that the compass or orientation readings from the movement sensor report `0` when the base is facing north.
-- If you cannot verify this:
-  - Navigate back to your machine's **CONFIGURE** tab.
-    Scroll to the card with the name of your movement sensor.
-    Adjust the `orientation` of the frame to compensate for the mismatch.
-  - Navigate back to the movement sensor card on your **CONTROL** page, and confirm that the compass or orientation readings from the movement sensor now report `0` when the base is facing north, confirming that you've successfully calibrated your machine to be oriented accurately within the frame system.
-  - If you cannot verify this, repeat as necessary.
-
-## API
-
-The [navigation service API](/reference/apis/services/navigation/) supports the following methods:
-
-{{< readfile "/static/include/services/apis/generated/navigation-table.md" >}}
-
-## Control tab usage
-
-After configuring the navigation service for your machine, navigate to the **CONTROL** tab of the machine's page and expand the card matching the name of your service to use an interface for rover navigation.
-
-Here, you can add waypoints and obstacles and view the position of your rover base on a map:
-
-{{<imgproc src="/services/navigation/navigation-control-card.png" resize="900x" style="width: 700px" alt="An example control interface for a navigation service in the  Control Tab.">}}
-
-## Navigation concepts
-
-The following concepts are important to understand when utilizing the navigation service.
-Each concept is a type of relative or absolute measurement, taken by a [movement sensor](/operate/reference/components/movement-sensor/), which can then be used by your machine to navigate across space.
-
-Here's how to use the following types of measurements:
-
-- [Compass Heading](/operate/reference/services/navigation/#compass-heading)
-- [Orientation](/operate/reference/services/navigation/#orientation)
-- [Angular Velocity](/operate/reference/services/navigation/#angular-velocity)
-- [Position](/operate/reference/services/navigation/#position)
-- [Linear Acceleration](/operate/reference/services/navigation/#linear-acceleration)
-- [Linear Velocity](/operate/reference/services/navigation/#linear-velocity)
-
-### Compass heading
-
-The following {{< glossary_tooltip term_id="model" text="models" >}} of [movement sensor](/operate/reference/components/movement-sensor/) take compass heading measurements:
-
-- [gps-nmea](https://github.com/viam-modules/gps/) - some GPS hardware only report heading while moving.
-- [gps-nmea-rtk-pmtk](https://github.com/viam-modules/gps/) - some GPS hardware only report heading while moving.
-- [gps-nmea-rtk-serial](https://github.com/viam-modules/gps/) - some GPS hardware only report heading while moving.
-- [imu-wit](https://github.com/viam-modules/wit-motion/)
-- [imu-wit-hwt905](https://github.com/viam-modules/wit-motion/)
-
-An example of a `CompassHeading` reading:
-
-```go
-// heading is a float64 between 0-360
-heading, err := gps.CompassHeading(context.Background(), nil)
-```
-
-Use compass heading readings to determine the _bearing_ of your machine, or, the [cardinal direction](https://en.wikipedia.org/wiki/Cardinal_direction) that your machine is facing.
-
-To read compass headings, [configure a capable movement sensor](/operate/reference/components/movement-sensor/#configuration) on your machine.
-Then use the movement sensor API's [`GetCompassHeading()`](/reference/apis/components/movement-sensor/#getcompassheading) method to get readings from the sensor.
-
-### Orientation
-
-The following {{< glossary_tooltip term_id="model" text="models" >}} of [movement sensor](/operate/reference/components/movement-sensor/) take orientation measurements:
-
-- [imu-wit](https://github.com/viam-modules/wit-motion/)
-- [imu-wit-hwt905](https://github.com/viam-modules/wit-motion/)
-- [wheeled-odometry](/operate/reference/components/movement-sensor/wheeled-odometry/)
-
-An example of an `Orientation` reading:
-
-```go
-// orientation is a OrientationVector struct with OX, OY, OZ denoting the coordinates of the vector and rotation about z-axis, Theta
-orientation, err := imuwit.Orientation(context.Background(), nil)
-```
-
-Use orientation readings to determine the orientation of an object in 3D space as an [_orientation vector_](/motion-planning/reference/orientation-vectors/).
-An orientation vector indicates how it is rotated relative to an origin coordinate system around the x, y, and z axes.
-You can choose the origin reference frame by configuring it using Viam's [frame system](/operate/reference/services/frame-system/).
-The `GetOrientation` readings will report orientations relative to that initial frame.
-
-To read orientation, first [configure a capable movement sensor](/operate/reference/components/movement-sensor/#configuration) on your machine.
-Additionally, follow [these instructions](/operate/reference/services/frame-system/#configuration) to configure the geometries of each component of your machine within the frame system.
-Then use the movement sensor API's [`GetOrientation()`](/reference/apis/components/movement-sensor/#getorientation) method to get orientation readings.
-
-### Angular velocity
-
-The following {{< glossary_tooltip term_id="model" text="models" >}} of the [movement sensor](/operate/reference/components/movement-sensor/) component take angular velocity measurements:
-
-- [imu-wit](https://github.com/viam-modules/wit-motion/)
-- [imu-wit-hwt905](https://github.com/viam-modules/wit-motion/)
-- [wheeled-odometry](/operate/reference/components/movement-sensor/wheeled-odometry/)
-- [gyro-mpu6050](https://github.com/viam-modules/tdk-invensense/)
-
-An example of an `AngularVelocity` reading:
-
-```go
-// angularVelocity is an AngularVelocity r3 Vector with X, Y, and Z magnitudes
-angularVelocity, err := imu.AngularVelocity(context.Background(), nil)
-```
-
-Use angular velocity readings to determine the speed and direction at which your machine is rotating.
-
-To get an angular velocity reading, first [configure a capable movement sensor](/operate/reference/components/movement-sensor/#configuration) on your machine.
-Then use the movement sensor API's [`GetAngularVelocity()`](/reference/apis/components/movement-sensor/#getangularvelocity) method to get angular velocity readings from the sensor.
-
-### Position
-
-The following {{< glossary_tooltip term_id="model" text="models" >}} of the [movement sensor](/operate/reference/components/movement-sensor/) component take position measurements:
-
-- [gps-nmea](https://github.com/viam-modules/gps/)
-- [gps-nmea-rtk-pmtk](https://github.com/viam-modules/gps/)
-- [gps-nmea-rtk-serial](https://github.com/viam-modules/gps/)
-- [wheeled-odometry](/operate/reference/components/movement-sensor/wheeled-odometry/)
-
-An example of a `Position` reading:
-
-```go
-// position is a geo.Point consisting  of Lat and Long: -73.98 and an altitude in float64
-position, altitude, err := imu.Position(context.Background(), nil)
-```
-
-Use position readings to determine the GPS coordinates of an object in 3D space or its position in the geographic coordinate system [(GCS)](https://en.wikipedia.org/wiki/Geographic_coordinate_system).
-These position readings reflect the _absolute_ position of components.
-
-To get a position, [configure a capable movement sensor](/operate/reference/components/movement-sensor/#configuration) on your machine.
-Then use the movement sensor API's [`GetPosition()`](/reference/apis/components/movement-sensor/#getposition) method to get position readings from the sensor.
-
-### Linear velocity
-
-The following {{< glossary_tooltip term_id="model" text="models" >}} of [movement sensor](/operate/reference/components/movement-sensor/) take linear velocity measurements:
-
-- [gps-nmea](https://github.com/viam-modules/gps/)
-- [gps-nmea-rtk-pmtk](https://github.com/viam-modules/gps/)
-- [gps-nmea-rtk-serial](https://github.com/viam-modules/gps/)
-- [wheeled-odometry](/operate/reference/components/movement-sensor/wheeled-odometry/) (provides a relative estimate only based on where the base component has started)
-
-An example of a `LinearVelocity` reading:
-
-```go
-// linearVelocity is an r3.Vector with X, Y, and Z magnitudes
-linearVelocity, err := imu.LinearVelocity(context.Background(), nil)
-```
-
-Use linear velocity readings to determine the speed at which your machine is moving through space.
-
-To get linear velocity, [configure a capable movement sensor](/operate/reference/components/movement-sensor/#configuration) on your machine.
-Then use the movement sensor API's [`GetLinearVelocity()`](/reference/apis/components/movement-sensor/#getlinearvelocity) method to get linear velocity readings from the sensor.
-
-### Linear acceleration
-
-The following {{< glossary_tooltip term_id="model" text="models" >}} of [movement sensor](/operate/reference/components/movement-sensor/) take linear acceleration measurements:
-
-- [accel-adxl345](https://github.com/viam-modules/analog-devices/)
-- [imu-wit](https://github.com/viam-modules/wit-motion/)
-- [imu-wit-hwt905](https://github.com/viam-modules/wit-motion/)
-- [gyro-mpu6050](https://github.com/viam-modules/tdk-invensense/)
-
-An example of a `LinearAcceleration` reading:
-
-```go
-// linearAcceleration is an r3.Vector with X, Y, and Z magnitudes
-linearAcceleration, err := imu.LinearAcceleration(context.Background(), nil)
-```
-
-You can use linear acceleration readings to determine the rate of change of the [linear velocity](/operate/reference/services/navigation/#linear-velocity) of your machine, or, the acceleration at which your machine is moving through space.
-
-To get linear acceleration, [configure a capable movement sensor](/operate/reference/components/movement-sensor/#configuration) on your machine.
-Then use the movement sensor API's [`GetLinearAcceleration()`](/reference/apis/components/movement-sensor/#getlinearacceleration) method to get linear acceleration readings from the sensor.
-
-## Next steps
-
-If you would like to see the navigation service in action, check out this tutorial:
-
-{{< cards >}}
-{{% card link="/tutorials/services/navigate-with-rover-base/" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/services/slam/_index.md b/docs/operate/reference/services/slam/_index.md
deleted file mode 100644
index 30ac5e2281..0000000000
--- a/docs/operate/reference/services/slam/_index.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: "SLAM Service"
-linkTitle: "SLAM"
-weight: 60
-type: "docs"
-description: "Simultaneous localization and mapping (SLAM) allows your machine to create a map of its surroundings and find its location within that map."
-tags: ["slam", "services"]
-icon: true
-images: ["/services/icons/slam.svg"]
-no_list: true
-aliases:
-  - "/services/slam/"
-  - "/mobility/slam/"
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: John N.
----
-
-{{% alert title="Stability Notice" color="note" %}}
-The SLAM service is an experimental feature.
-Stability is not guaranteed.
-Breaking changes are likely to occur, and occur often.
-{{% /alert %}}
-
-[Simultaneous Localization And Mapping (SLAM)](https://en.wikipedia.org/wiki/Simultaneous_localization_and_mapping) allows your machine to create a map of its surroundings and find its location within that map.
-SLAM is an important area of ongoing research in robotics, particularly for mobile applications such as drones, boats, and rovers.
-
-The Viam SLAM service supports the integration of SLAM as a service on your machine.
-You can conduct SLAM with data collected live by a [RPlidar](https://github.com/viamrobotics/rplidar) or with LIDAR data you provide in configuration, and easily view the map you build by clicking on **View SLAM library** on your location's page:
-
-![Completed SLAM maps in the SLAM library tab](/services/slam/view-map-page.png)
-
-## Used with
-
-<!-- markdownlint-disable MD034 -->
-
-{{< cards >}}
-{{< relatedcard link="/operate/reference/components/camera/" alt_title="RPlidar" alt_link="https://github.com/viamrobotics/rplidar" required="yes">}}
-{{< relatedcard link="/operate/reference/components/movement-sensor/" required="no" >}}
-{{< relatedcard link="/operate/reference/components/base/" required="no" >}}
-{{< /cards >}}
-
-{{% snippet "required-legend.md" %}}
-
-## Configuration
-
-Integrated SLAM libraries include the following.
-Click the model name for configuration instructions.
-
-<!-- prettier-ignore -->
-| Model | Description |
-| ----- | ----------- |
-| [`viam:slam:cartographer`](cartographer/) | [The Cartographer Project](https://github.com/cartographer-project) performs dense SLAM using LIDAR data. |
-| [`viam:cloudslam-wrapper:cloudslam`](cloudslam/) | [cloudslam-wrapper](https://github.com/viam-modules/cloudslam-wrapper) Allows you to run supported SLAM algorithms in the cloud. |
-
-## API
-
-The [SLAM service API](/reference/apis/services/slam/) supports the following methods:
-
-{{< readfile "/static/include/services/apis/generated/slam-table.md" >}}
-
-## SLAM mapping best practices
-
-The best way to improve map quality is by taking extra care when creating the initial map.
-While in a slam session, you should:
-
-- turn gently and gradually, completely avoiding sudden quick turns
-- make frequent loop closures, arriving back at a previously mapped area so the machine can correct for errors in the map layout
-- stay relatively (but not extremely) close to walls
-- use a machine that can go smoothly over bumps and transitions between flooring areas
-- drive at a moderate speed
-- when using a wheeled base, try to include an [odometry movement sensor](/operate/reference/components/movement-sensor/wheeled-odometry/). This helps the SLAM algorithm keep track of where the machine is moving.
-- it is important to note that the [adxl345 accelerometer](https://github.com/viam-modules/analog-devices/) on the [Viam Rover 1](/try/rover-resources/rover-tutorial-1/) **will not** satisfy the movement sensor requirement.
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
diff --git a/docs/operate/reference/services/slam/cartographer/_index.md b/docs/operate/reference/services/slam/cartographer/_index.md
deleted file mode 100644
index 61453bedff..0000000000
--- a/docs/operate/reference/services/slam/cartographer/_index.md
+++ /dev/null
@@ -1,474 +0,0 @@
----
-title: "Cartographer Modular Resource"
-linkTitle: "Cartographer"
-weight: 70
-type: "docs"
-description: "Configure a Simultaneous Localization And Mapping (SLAM) service with the Cartographer modular resource."
-tags: ["slam", "services"]
-icon: true
-images: ["/services/icons/slam.svg"]
-aliases:
-  - "/services/slam/run-slam-cartographer/"
-  - "/services/slam/cartographer/"
-  - "/mobility/slam/cartographer/"
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: John N.
----
-
-[The Cartographer Project](https://github.com/cartographer-project) contains a C++ library that performs dense Simultaneous Localization And Mapping (SLAM).
-
-To use Cartographer with the Viam {{< glossary_tooltip term_id="slam" text="SLAM" >}} service, you can use the [`cartographer`](https://app.viam.com/module/viam/cartographer) {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}}.
-
-The source code for this module is available on the [`viam-cartographer` GitHub repository](https://github.com/viamrobotics/viam-cartographer).
-
-{{% alert title="Info" color="info" %}}
-
-Currently, the `cartographer` modular resource supports taking 2D LiDAR and optionally IMU and/or odometry data as input.
-
-Support for taking 3D LiDAR data as input may be added in the future.
-
-{{% /alert %}}
-
-## Using Cartographer
-
-The `cartographer` module supports three modes of operation:
-
-- [Create a new map](#create-a-new-map)
-- [Update an existing map](#update-an-existing-map)
-- [Pure localization](#localize-only)
-
-### Hardware requirements
-
-{{% alert title="Running cartographer in the cloud" color="info" %}}
-
-Creating and updating SLAM maps with Cartographer is especially CPU-intensive.
-If you do not have enough resources locally, you can use the [cloudslam wrapper module](../cloudslam/) to move computation to the cloud.
-
-Running `cartographer` in the cloud incurs cost for Data Management, Cloud Data Upload, and Cloud Data Egress. Currently, you incur no cost for compute.
-See Viam's [Pricing](https://www.viam.com/product/pricing) for more information.
-
-{{% /alert %}}
-
-#### RPLidar
-
-- You must have an RPlidar, such as the [RPlidar A1](https://www.slamtec.com/en/Lidar/A1) or [RPlidar A3](https://www.slamtec.com/en/Lidar/A3), physically connected to your machine.
-
-  Be sure to position the RPlidar so that it **faces forward in the direction of travel**. For example, if you are using a [Viam Rover](https://www.viam.com/resources/rover) and the [RPlidar A1](https://www.slamtec.com/en/Lidar/A1) model, mount it to the Rover so that the **pointed** end of the RPlidar mount housing is facing in the same direction as the webcam.
-
-  Furthermore, ensure that the center of the RPlidar is mounted at the center of your machine's [base](/operate/reference/components/base/).
-  In the case of the Viam Rover the center is in the middle between the wheels.
-
-  If you need a **mount plate** for your RPlidar A1 or A3 model, you can 3D print an adapter plate using the following:
-
-  - [RPlidar A1 adapter STL](https://github.com/viamrobotics/Rover-VR1/blob/master/CAD/RPIidarA1_adapter.STL)
-  - [RPlidar A3 adapter STL](https://github.com/viamrobotics/Rover-VR1/blob/master/CAD/RPIidarA3_adapter.STL)
-
-- In addition, you must [add the `rplidar` module to your machine](https://github.com/viamrobotics/rplidar) to support the RPlidar hardware, if you have not done so already.
-
-  {{< alert title="SUPPORT" color="note" >}}
-
-  Currently, the `rplidar` and `cartographer` modules only support the Linux platform.
-
-  {{< /alert >}}
-
-#### Movement sensors (optional)
-
-You can use data from one or more movement sensors on your machine to supplement the required LiDAR data.
-If you choose to use movement sensor data for SLAM, you can:
-
-- Add only inertial measurement unit (IMU) data
-  - Requires a movement sensor that supports [`AngularVelocity`](/operate/reference/services/navigation/#angular-velocity) and [`LinearAcceleration`](/operate/reference/services/navigation/#linear-acceleration) readings
-- Add only odometry data
-  - Requires a movement sensor that collects [`Position`](/operate/reference/services/navigation/#position) and [`Orientation`](/operate/reference/services/navigation/#orientation) data (for example, [`wheeled-odometry`](/operate/reference/components/movement-sensor/wheeled-odometry/))
-- Add both IMU _and_ odometry data
-  - Requires all four of the above kinds of data, merged together using the [`merged` movement sensor model](/operate/reference/components/movement-sensor/merged/)
-  - If you choose this option, be sure to configure data capture on the `merged` sensor and not on the individual movement sensors when following the steps below.
-
-### Create a new map
-
-To create a new map, follow the instructions below.
-
-{{< tabs name="Create new map">}}
-{{% tab name="Config Builder" %}}
-
-1. Ensure any sensors you wish to use are configured on the machine. See the [Hardware Requirements](#hardware-requirements) above.
-
-2. Set up the `cartographer` module on your machine:
-
-   Navigate to the **CONFIGURE** tab of your machine's page.
-
-   Click the **+** icon next to your machine part in the left-hand menu and select **Service**.
-   Select **SLAM**, then select `cartographer`.
-   You can also search for "cartographer".
-
-   Click **Add module**, give your service a name of your choice, then click **Create**.
-
-   In the resulting `SLAM` service configuration pane, choose `Create new map` as the **Mapping mode**, then configure the rest of the **Attributes** for that mapping mode:
-
-   - **Camera**: Select the `name` of the camera component that you created when you [added the `rplidar` module to your machine](https://github.com/viamrobotics/rplidar).
-     Example: "my-rplidar". Then set the `Data polling rate (Hz)` for retrieving pointclouds from the camera. For RPLidar A1 and A3 we recommend a frequency of 5 Hz.
-   - **Movement Sensor (Optional)**: Select the `name` of the movement sensor component that you want to use for SLAM.
-     If you are using both an IMU _and_ an odometer, select the `name` of the `merged` movement sensor, _not_ the `name` of either of the individual movement sensors.
-     Examples: "my-imu", "MyOdometer," or "merged-ms". Then set the `Data polling rate (Hz)` for retrieving readings from the movement sensor. We recommend a frequency of 20 Hz.
-   - **Minimum range (meters)**: Set the minimum range of your `rplidar`.
-     See [config params](#config_params) for suggested values for RPLidar A1 and A3.
-   - **Maximum range (meters)**: Set the maximum range of your `rplidar`.
-     See [config params](#config_params) for suggested values for RPLidar A1 and A3.
-
-   If you would like to tune additional Cartographer parameters, click the **JSON** button to switch to the JSON editor, then edit the `config_params` from there.
-   See the [`config_params`](#config_params) section for more information on the other parameters.
-
-   To save your changes, click the **Save** button in the top right corner of the page.
-
-   Check the **LOGS** tab of your machine to make sure your RPlidar has connected and no errors are being raised.
-
-3. (Optional) Configure cartographer to use cloudSLAM:
-
-   On the `SLAM` service configuration pane, click the **JSON** button to switch to the JSON editor and set the `use_cloud_slam` field to **true**. This setting disables local mapping to limit CPU usage in favor of using cloudSLAM.
-
-   In addition, your configured LiDAR camera and movement sensor must have data capture enabled. See the [cloudSLAM](../cloudslam/) documentation for more information on how to configure the feature on your machine and how to use cloudSLAM.
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-This example JSON configuration:
-
-- adds the `viam:rplidar` and the `viam:cartographer` modules
-- configures the `viam:slam:cartographer` service
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "modules": [
-    {
-      "type": "registry",
-      "name": "viam_rplidar",
-      "module_id": "viam:rplidar",
-      "version": "0.1.16"
-    },
-    {
-      "type": "registry",
-      "name": "viam_cartographer",
-      "module_id": "viam:cartographer",
-      "version": "0.3.45"
-    }
-  ],
-  "services": [
-    {
-      "attributes": {
-        "config_params": {
-          "max_range_meters": "25",
-          "mode": "2d",
-          "min_range_meters": "0.2"
-        },
-        "camera": {
-          "name": "rplidar",
-          "data_frequency_hz": "5"
-        },
-        "enable_mapping": true,
-        "use_cloud_slam": false
-      },
-      "name": "slam",
-      "api": "rdk:service:slam",
-      "model": "viam:slam:cartographer"
-    }
-  ],
-  "components": [
-    {
-      "attributes": {},
-      "depends_on": [],
-      "name": "rplidar",
-      "model": "viam:lidar:rplidar",
-      "api": "rdk:component:camera"
-    }
-  ]
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-For more information about the configuration attributes, see [Attributes](#attributes).
-
-After configuring cartographer the machine should begin mapping automatically. Navigate to the **CONTROL** tab on your machine's page and click on the dropdown menu matching the `name` of the service you created. See our [tips](../#slam-mapping-best-practices) for making good maps. If you want to save your locally built map, you can use the **GetInternalState API** or use the local map uploading feature of the [cloudslam wrapper module](../cloudslam/).
-
-### Update an existing map
-
-To update an existing map with new pointcloud data from a new SLAM session, follow the instructions below.
-
-1. Configure your `cartographer` SLAM service using a map from your location:
-
-   {{< tabs name="Update existing map">}}
-   {{% tab name="Config Builder" %}}
-
-   1. Select the Mapping mode dropdown and choose the **Update existing map** option.
-   2. Configure **Select map** and **Map version** with the name and version of the map you would like to update.
-      For the other attributes, review the information in [Create a new map](#create-a-new-map).
-      You can see more details about the available maps from your machine's **Location** page by clicking **View SLAM library**.
-
-   {{% /tab %}}
-   {{% tab name="JSON Example" %}}
-
-   This example JSON configuration:
-
-   - adds the `viam:rplidar` and the `viam:cartographer` modules
-   - configures the `viam:slam:cartographer` service
-   - adds an `viam:lidar:rplidar` camera
-   - specifies the `slam_map` to be updated in the `packages`
-
-   <br>
-
-   ```json {class="line-numbers linkable-line-numbers"}
-   {
-     "modules": [
-       {
-         "type": "registry",
-         "name": "viam_rplidar",
-         "module_id": "viam:rplidar",
-         "version": "0.1.16"
-       },
-       {
-         "type": "registry",
-         "name": "viam_cartographer",
-         "module_id": "viam:cartographer",
-         "version": "0.3.45"
-       }
-     ],
-     "services": [
-       {
-         "attributes": {
-           "config_params": {
-             "max_range_meters": "25",
-             "mode": "2d",
-             "min_range_meters": "0.2"
-           },
-           "camera": {
-             "name": "rplidar",
-             "data_frequency_hz": "5"
-           },
-           "enable_mapping": true,
-           "use_cloud_slam": false,
-           "existing_map": "${packages.slam_map.test-map-1}/internalState.pbstream"
-         },
-         "name": "slam",
-         "api": "rdk:service:slam",
-         "model": "viam:slam:cartographer"
-       }
-     ],
-     "components": [
-       {
-         "attributes": {},
-         "depends_on": [],
-         "name": "rplidar",
-         "model": "viam:lidar:rplidar",
-         "api": "rdk:component:camera"
-       }
-     ],
-     "packages": [
-       {
-         "name": "test-map-1",
-         "version": "1697208847",
-         "package": "d1c224e8-483e-4cc7-980f-76b89d8fb507/test-map-1",
-         "type": "slam_map"
-       }
-     ]
-   }
-   ```
-
-   {{% /tab %}}
-   {{< /tabs >}}
-
-   For more information about the configuration attributes, see [Attributes](#attributes).
-
-   If you want to configure cartographer to use a locally saved map instead, see [Using locally built maps](#using-locally-built-maps).
-
-2. After configuring cartographer the machine should begin mapping automatically. Navigate to the **CONTROL** tab on your machine's page and click on the dropdown menu matching the `name` of the service you created.
-
-See our [tips](../#slam-mapping-best-practices) for making a good map! If you want to save your locally built map, you can use the **GetInternalState API** or use the local map uploading feature of the [cloudslam wrapper module](../cloudslam/)
-
-{{% alert title="Info" color="info" %}}
-
-Cartographer may take several minutes to find your machine's position on the existing map.
-In the meantime, your machine will show up at the map's origin (with the `(x,y)` coordinates `(0,0)`).
-
-{{% /alert %}}
-
-### Localize only
-
-In this mode, the `cartographer` module on your machine executes the Cartographer algorithm to find its position on a map. This mode is better when using [motion planning's MoveOnMap](/reference/apis/services/motion/#moveonmap) because the map will not be modified.
-
-1.  Configure your `cartographer` SLAM service:
-
-    {{< tabs name="Localize only">}}
-    {{% tab name="Config Builder" %}}
-
-1.  Select the Mapping mode dropdown and choose the **Update existing map** option.
-1.  Configure **Select map** and **Map version** with the name and version of the map you would like to localize on.
-    For the other attributes, review the information in [Create a new map](#create-a-new-map).
-    You can see more details about the available maps from your machine's **Location** page by clicking **View SLAM library**.
-
-    {{% /tab %}}
-    {{% tab name="JSON Example" %}}
-
-This example JSON configuration:
-
-- adds the `viam:rplidar` and the `viam:cartographer` modules
-- configures the `viam:slam:cartographer` service
-- adds an `viam:lidar:rplidar`
-- specifies the `slam_map` for localization in the `packages`
-
-<br>
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "modules": [
-    {
-      "type": "registry",
-      "name": "viam_rplidar",
-      "module_id": "viam:rplidar",
-      "version": "0.1.16"
-    },
-    {
-      "type": "registry",
-      "name": "viam_cartographer",
-      "module_id": "viam:cartographer",
-      "version": "0.3.45"
-    }
-  ],
-  "services": [
-    {
-      "api": "rdk:service:slam",
-      "model": "viam:slam:cartographer",
-      "attributes": {
-        "config_params": {
-          "min_range_meters": "0.2",
-          "max_range_meters": "25",
-          "mode": "2d"
-        },
-        "camera": {
-          "name": "rplidar",
-          "data_frequency_hz": "5"
-        },
-        "enable_mapping": false,
-        "use_cloud_slam": false,
-        "existing_map": "${packages.slam_map.test-map-1}/internalState.pbstream"
-      },
-      "name": "slam"
-    }
-  ],
-  "components": [
-    {
-      "model": "viam:lidar:rplidar",
-      "api": "rdk:component:camera",
-      "attributes": {},
-      "depends_on": [],
-      "name": "rplidar"
-    }
-  ],
-  "packages": [
-    {
-      "type": "slam_map",
-      "name": "test-map-1",
-      "version": "1697208847",
-      "package": "d1c224e8-483e-4cc7-980f-76b89d8fb507/test-map-1"
-    }
-  ]
-}
-```
-
-    {{% /tab %}}
-    {{< /tabs >}}
-
-    For more information about the configuration attributes, see [Attributes](#attributes).
-
-    If you want to configure cartographer to use a locally saved map instead, see [Using locally built maps](#using-locally-built-maps).
-
-2. After configuring cartographer on the machine, the map should appear automatically. Navigate to the **CONTROL** tab on your machine's page and click on the dropdown menu matching the `name` of the service you created.
-
-   {{% alert title="Info" color="info" %}}
-
-Cartographer may take several minutes to find your machine's position on the existing map.
-In the meantime, your machine will show up at the map's origin (with the `(x,y)` coordinates `(0,0)`).
-
-If you move your machine, it will appear to be moving in a trajectory from the map's origin.
-
-    {{% /alert %}}
-
-### Attributes
-
-<!-- prettier-ignore -->
-| Name | Data Type | Required? | Description |
-| ---- | --------- | --------- | ----------- |
-| `use_cloud_slam` | boolean | **Required** | If `true`, the Cartographer algorithm will disable mapping on the machine. This feature should only be used when trying to use [cloudslam](../cloudslam/). |
-| `camera` | obj | **Required** | An object of the form `{ "name": <string>, "data_frequency_hz": <int> }` where `name` is the name of the LiDAR camera component to use as input and `data_frequency_hz` is the rate at which to capture (in "Create new map" or "Update existing map" modes) or poll (in "Localize only" mode) data from that camera component. |
-| `movement_sensor` | obj | Optional | An object of the form `{ "name": <string>, "data_frequency_hz": <int> }` where `name` is the name of the IMU movement sensor (that is, a movement sensor that supports the `GetAngularVelocity` and `GetLinearAcceleration` API methods) to use as additional input and `data_frequency_hz` is the rate at which to capture (in "Create new map" or "Update existing map" modes) or poll (in "Localize only" mode) data from that movement sensor component. |
-| `enable_mapping` | boolean | Optional | If `true`, Cartographer will build the map in addition to doing localization. <ul> Default: `true` </ul> |
-| `existing_map` | string | Optional | The alias of the package containing the existing map to build on (in "Update existing map" mode) or localize on (in "Localize only" mode). Can also point to a locally saved `.pbstream` file. |
-| `config_params` |  obj | Optional | Parameters available to fine-tune the `cartographer` algorithm: [read more below](#config_params). |
-
-#### `config_params`
-
-{{< readfile "/static/include/services/cartographer/configparams.md" >}}
-
-### Using locally built maps
-
-You can see details about the available maps from your machine's **Location** page by clicking **View SLAM library**.
-If you do not have any maps, and you do not wish to use [cloudslam](../cloudslam/), but you still want to use localizing and updating modes with cartographer, you can take the following steps.
-
-1. Save a `.pbstream` file by using the [GetInternalState or InternalStateFull APIs](../#api) by using one of the SDKs. Note, `InternalStateFull` is currently only implemented in Go.
-2. Ensure the `.pbstream` file is located somewhere on the machine, and note the directory path to that file.
-3. In your cartographer's config, update the `existing_map` field with the path to the file that was noted in #2.
-
-your config should look something like the following:
-
-```json {class="line-numbers linkable-line-numbers"}
-{
-  "modules": [
-    {
-      "type": "registry",
-      "name": "viam_rplidar",
-      "module_id": "viam:rplidar",
-      "version": "0.1.16"
-    },
-    {
-      "type": "registry",
-      "name": "viam_cartographer",
-      "module_id": "viam:cartographer",
-      "version": "0.3.45"
-    }
-  ],
-  "services": [
-    {
-      "attributes": {
-        "config_params": {
-          "max_range_meters": "25",
-          "mode": "2d",
-          "min_range_meters": "0.2"
-        },
-        "camera": {
-          "name": "rplidar",
-          "data_frequency_hz": "5"
-        },
-        "enable_mapping": true,
-        "use_cloud_slam": false,
-        "existing_map": "/PATH/TO/FILE/<INTERNAL-STATE-NAME>.pbstream"
-      },
-      "name": "slam",
-      "api": "rdk:service:slam",
-      "model": "viam:slam:cartographer"
-    }
-  ],
-  "components": [
-    {
-      "attributes": {},
-      "depends_on": [],
-      "name": "rplidar",
-      "model": "viam:lidar:rplidar",
-      "api": "rdk:component:camera"
-    }
-  ],
-  "packages": []
-}
-```
-
-Now your `cartographer` service should be running using your locally saved map.
diff --git a/docs/operate/reference/services/slam/cloudslam/_index.md b/docs/operate/reference/services/slam/cloudslam/_index.md
deleted file mode 100644
index 68fdde87f3..0000000000
--- a/docs/operate/reference/services/slam/cloudslam/_index.md
+++ /dev/null
@@ -1,442 +0,0 @@
----
-title: "CloudSLAM Wrapper Modular Resource"
-linkTitle: "CloudSLAM"
-weight: 70
-type: "docs"
-description: "Configure a Simultaneous Localization And Mapping (SLAM) service that runs in the cloud using Viam."
-tags: ["slam", "services"]
-icon: true
-images: ["/services/icons/slam.svg"]
-date: "2022-01-01"
-aliases:
-  - /services/slam/cloudslam/
-# updated: ""  # When the content was last entirely checked
-# SMEs: John N.
----
-
-SLAM Algorithms can have varying levels of resource requirements in order to run effectively.
-`Cartographer` in particular can require a significant amount of CPU resources to build and manage large maps.
-In order to better support running SLAM on resource limited machines, Viam provides a service to run SLAM algorithms for machines in the cloud as well as management of the maps generated in their location.
-
-CloudSLAM can be used with both a live machine or with previously captured data in your location.
-In [live mode](#mapping-with-a-live-machine-online-mode) using the [data management service](/data/capture-sync/capture-and-sync-data/) and the [cloudslam-wrapper](https://github.com/viam-modules/cloudslam-wrapper) module, Viam takes your LiDAR camera and movement sensor data from your local machine and sends it to the cloudslam server.
-The CloudSLAM server will then process that data and produce a map that can then be used on any machine in your location.
-When using an [offline machine](#using-previously-captured-data-offline-mode), you can select data from specific sensors over a period of time to build a map with.
-
-You can view and delete maps built in a location by going to the [SLAM library](#the-slam-library-page), which provides a summary of active jobs in the location as well as a list of all maps built in that location.
-
-If you have your own SLAM algorithm that we do not currently support or if you built a map on your local machine already and want to skip running CloudSLAM, you can [upload a locally built map](#upload-a-locally-built-map) to your location using the `cloudslam-wrapper` module.
-
-{{% alert title="About Pricing" color="info" %}}
-
-Running `cloudslam` incurs cost for Data Management, Cloud Data Upload, and Cloud Data Egress. Currently, you incur no cost for compute.
-See Viam's [Pricing](https://www.viam.com/product/pricing) for more information.
-
-{{% /alert %}}
-
-## Supported algorithms
-
-Currently CloudSLAM only supports the [cartographer module](../cartographer/) as a SLAM algorithm.
-
-## The SLAM library page
-
-You can see details about the available maps from your machine's **Location** page by clicking **View SLAM library**.
-From here, you can find:
-
-1.  A list of all maps generated in that location. The list shows the name and version of the map, which machine was used for mapping, and when the map was created. You can also view previous versions of a map, if a map has been updated multiple times.
-    ![offline mapping available maps](/services/slam/offline-mapping-available-maps.png)
-
-2.  You can create or update a map using a previously collected dataset by clicking the **Make new map** on the top right and specify a map name or click **Update map** next to an existing map. See [using previously captured data](#using-previously-captured-data-offline-mode) for more information on how to do this.
-
-3.  A table showing active and failed CloudSLAM sessions.
-    The table highlights the name of the map, which machine is currently mapping, and whether the map is in progress or has failed.
-    You can also use the table view to stop active mapping sessions.
-    ![offline mapping maps computing table](/services/slam/offline-mapping-maps-computing-table.png)
-
-4.  You can view maps in more detail in a dynamic pointcloud viewer by selecting the `View Map` button on one
-    ![slam library view map](/services/slam/slam-library-view-map.png)
-
-5.  You can delete maps by clicking on the trash can icon in the upper right-hand corner of a map's card.
-
-## Mapping with a live machine (Online Mode)
-
-To run SLAM in the cloud, configure the [`cloudslam-wrapper`](https://app.viam.com/module/viam/cloudslam-wrapper) module and data capture on your machine.
-
-### Requirements
-
-To use CloudSLAM on a live machine, you must meet the following requirements:
-
-1. A cloudslam supported algorithm must be configured on the machine. Currently only the [cartographer module](../cartographer/) is supported.
-   Please configure a supported algorithm on the machine before continuing.
-
-2. A location owner [API key](/manage/manage/access/) or higher.
-
-### Configuration
-
-To use CloudSLAM you must enable data capture and configure your `cloudslam-wrapper` SLAM service:
-
-{{< alert title="Tip: Managing Data Capture" color="tip" >}}
-Note that when the [data management service](/data/capture-sync/capture-and-sync-data/) is enabled, it continuously monitors and syncs your machine’s sensor data while the machine is running.
-To avoid incurring charges while not in use, [turn off data capture for your sensors](/data/capture-sync/capture-and-sync-data/#stop-data-capture-or-data-sync) once you have finished your SLAM session.
-{{< /alert >}}
-
-{{< tabs name="Create new map">}}
-{{% tab name="Config Builder" %}}
-
-1. Add the data management service to your machine:
-
-   Navigate to the **CONFIGURE** tab of your machine's page.
-   Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-   Choose **Data Management** as the type and either use the suggested name or specify a name for your data management service, for example `data_manager-1`.
-   Click **Create**.
-
-   On the panel that appears, you can manage the capturing and syncing functions.
-   You can also specify the **directory**, the sync **interval**, and any **tags** to apply to captured data.
-   See the [data management service](/data/capture-sync/capture-and-sync-data/) for more information.
-
-2. Enable data capture for your camera, and for your movement sensor if you would like to use IMU data, odometry data, or both:
-
-   Find the component's card on your machine's **CONFIGURE** tab.
-   Click **Add Method**, then select the method type and specify the capture frequency.
-
-   - For the required LiDAR camera, choose the `NextPointCloud` method.
-     Then set the capture frequency.
-     `5 Hz` is a good starting place for most applications.
-
-     {{<imgproc src="/services/slam/rplidar-capture.png" resize="x1100" declaredimensions=true alt="An R P lidar camera configured with next point cloud configured for capture at 5 Hz." class="shadow"  >}}
-
-   - To capture data from one or more movement sensors:
-
-{{< tabs name="Movement sensor options" >}}
-{{% tab name="IMU only" %}}
-
-For an IMU, choose the `AngularVelocity` and `LinearAcceleration` methods and set the capture frequency.
-`20 Hz` is a good starting place for most applications.
-
-{{<imgproc src="/services/slam/imu-capture.png" resize="x1100" declaredimensions=true alt="An IMU configured with angular velocity and linear acceleration both configured for capture at 20 Hz." class="shadow" >}}
-
-{{% /tab %}}
-{{% tab name="Odometry only" %}}
-
-For a movement sensor that supports odometry, choose the `Position` and `Orientation` methods and set the capture frequency.
-`20 Hz` is a good starting place for most applications.
-
-{{<imgproc src="/services/slam/odometer-capture.png" resize="x1100" declaredimensions=true alt="A wheeled odometer configured with position and orientation both configured for capture at 20 Hz." class="shadow" >}}
-
-{{% /tab %}}
-{{% tab name="Both (merged)" %}}
-
-For a `merged` movement sensor, choose all four methods (`AngularVelocity`, `LinearAcceleration`, `Position`, and `Orientation`) and set the capture frequency.
-`20 Hz` is a good starting place for most applications.
-You _do not_ need to configure data capture on the individual IMU and odometer.
-
-{{<imgproc src="/services/slam/merged-capture.png" resize="x1100" declaredimensions=true alt="An IMU configured with angular velocity, linear acceleration, position, and orientation all configured for capture at 20 Hz." class="shadow" >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-<br>
-
-3. Set up the `cloudslam-wrapper` module on your machine:
-
-   Navigate to the **CONFIGURE** tab of your machine's page.
-
-   Click the **+** icon next to your machine part in the left-hand menu and select **Component or service**.
-   Select **SLAM**, then select `cloudslam-wrapper`.
-   You can also search for "cloudslam".
-
-   Click **Add module**, give your service a name of your choice, then click **Create**.
-
-   In the resulting `SLAM` service configuration pane, add the following **Attributes**:
-
-   ```json
-   {
-     "slam_service": "<slam-service-name>",
-     "api_key": "<location-api-key>",
-     "api_key_id": "<location-api-key-id>",
-     "organization_id": "<organization_id>",
-     "location_id": "<location_id>",
-     "machine_id": "<machine_id>"
-   }
-   ```
-
-   where
-
-   - `slam_service` is the name of the slam service that you want to run with cloudslam.
-   - `api_key` and `api_key_id` are for the location owner API key described in the [requirements](#requirements).
-   - `organization_id`, `location_id`, and `machine_id` describe which location and organization you want to run cloudslam in. These are needed so we can fully tie the map you make to the machine running cloudslam.
-
-4. (Optional) configure the `cloudslam-wrapper` to use updating mode.
-   If you want cloudslam to update a `slam_map` rather than create a new map, do the following:
-
-   - configure the `slam_map` on your wrapped SLAM service
-   - add a `machine_part_id` to your `cloudslam-wrapper` config.
-
-   This informs the module to use the configured `slam_map` on your machine.
-
-5. Configure Cartographer to use cloudslam.
-
-   In your `cartographer` config card, click the **JSON** button to switch to the JSON editor and set the `use_cloud_slam` field to **true**. This setting disables local mapping to limit CPU usage in favor of using cloudslam.
-
-{{% /tab %}}
-{{% tab name="JSON Example" %}}
-
-This example JSON configuration:
-
-- adds the `viam:rplidar`, `viam:cartographer`, and `viam:cloudslam-wrapper` modules
-- configures the `viam:slam:cartographer`, `viam:cloudslam-wrapper:cloudslam`, and the [data management](/data/capture-sync/capture-and-sync-data/) services
-- adds a `viam:lidar:rplidar` camera with data capture configured
-
-  ```json {class="line-numbers linkable-line-numbers"}
-  {
-    "components": [
-      {
-        "name": "rplidar",
-        "api": "rdk:component:camera",
-        "model": "viam:lidar:rplidar",
-        "attributes": {},
-        "service_configs": [
-          {
-            "type": "data_manager",
-            "attributes": {
-              "capture_methods": [
-                {
-                  "method": "NextPointCloud",
-                  "capture_frequency_hz": 5,
-                  "additional_params": {}
-                }
-              ]
-            }
-          }
-        ]
-      }
-    ],
-    "services": [
-      {
-        "name": "carto",
-        "api": "rdk:service:slam",
-        "model": "viam:slam:cartographer",
-        "attributes": {
-          "enable_mapping": true,
-          "use_cloud_slam": true,
-          "existing_map": "",
-          "camera": {
-            "data_frequency_hz": "5",
-            "name": "rplidar"
-          }
-        }
-      },
-      {
-        "name": "data_manager-1",
-        "api": "rdk:service:data_manager",
-        "model": "rdk:builtin:builtin",
-        "attributes": {
-          "capture_dir": "",
-          "capture_disabled": false,
-          "sync_disabled": false,
-          "tags": [],
-          "additional_sync_paths": [],
-          "sync_interval_mins": 0.1
-        }
-      },
-      {
-        "name": "cloudslam",
-        "api": "rdk:service:slam",
-        "model": "viam:cloudslam-wrapper:cloudslam",
-        "attributes": {
-          "slam_service": "carto",
-          "api_key": "<location-api-key>",
-          "api_key_id": "<location-api-key-id>",
-          "organization_id": "<organization_id>",
-          "location_id": "<location_id>",
-          "machine_id": "<machine_id>",
-          "machine_part_id": "<machine-part-id>"
-        }
-      }
-    ],
-    "modules": [
-      {
-        "type": "registry",
-        "name": "viam_rplidar",
-        "module_id": "viam:rplidar",
-        "version": "0.1.16"
-      },
-      {
-        "type": "registry",
-        "name": "viam_cartographer",
-        "module_id": "viam:cartographer",
-        "version": "0.3.45"
-      },
-      {
-        "type": "registry",
-        "name": "viam_cloudslam-wrapper",
-        "module_id": "viam:cloudslam-wrapper",
-        "version": "0.0.3"
-      }
-    ]
-  }
-  ```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-For more information about the configuration attributes, see [Attributes](#attributes).
-
-### Running CloudSLAM
-
-Navigate to the **CONTROL** tab on your machine's page. Then check the following things:
-
-- (optional) change the refresh frequency on the `cartographer` card to **Manual Refresh**. Since you want to use CloudSLAM, you do not need to refresh the underlying SLAM algorithm's map.
-- the `cloudslam-wrapper` card should be displaying its default map.
-
-To start the mapping session, do the following:
-
-1. Scroll down to the **DoCommand** card
-2. Select your `cloudslam-wrapper` service name from the **Selected component** dropdown
-
-3. In the **Input** section, enter the following command:
-
-   ```json
-   { "start": "<MAPPING-SESSION-NAME>" }
-   ```
-
-   where `<MAPPING-SESSION-NAME>` is the name you want to give the map you wish to generate.
-
-4. Click the **Execute** button.
-
-   If everything is configured correctly, you should receive a success message.
-   The DoCommand card should look something like:
-   ![cloudslam wrapper docommand start](/services/slam/cloudslam-module-docommand-start.png)
-
-5. After roughly 1 minute, your map should appear on the `cloudslam-wrapper` card. The displayed map will now update roughly every 5 seconds with the current progress of the mapping session.
-
-You have now successfully built your map using CloudSLAM.
-Please review the [tips](../#slam-mapping-best-practices) for making good maps.
-![cloudslam wrapper map mapping](/services/slam/cloudslam-module-live-withmap.png)
-
-### Stopping cloudslam
-
-To stop a CloudSLAM mapping session, do the following:
-
-1. Scroll down to the **DoCommand** card
-2. Select your `cloudslam-wrapper` service name from the **Selected component** dropdown
-3. In the **Input** section, enter the following command:
-
-   ```json
-   { "stop": "" }
-   ```
-
-   You do not need to specify the map name or job ID here, as the module is already aware of any active mapping sessions for the machine.
-
-4. Click the **Execute** button.
-   If everything is configured correctly, you will receive a success message.
-   The DoCommand card should look something like:
-   ![cloudslam wrapper docommand start](/services/slam/cloudslam-module-docommand-stop.png)
-
-Once completed, you can view the final map in the `cloudslam-wrapper` card, or view the map in the [SLAM library](#the-slam-library-page).
-
-## Using previously captured data (Offline mode)
-
-You can specify a range of **previously captured** LiDAR and optional IMU data to create a map or update an existing map in the cloud.
-You can browse your previously captured data from the **Data** page under the **Point clouds** tab (for LiDAR data) and **Sensors** tab (for IMU data).
-
-### Requirements
-
-To create a map, you must have already captured LiDAR data in the location in which you would like to create the map.
-
-The following example shows the previously-captured LiDAR data under the **Point clouds** tab for a machine named `test`.
-Selecting a row opens a pane to the right that contains more information, such as the Machine ID of the machine the component belongs to:
-
-{{<imgproc src="/services/slam/offline-mapping-pointcloud-data.png" resize="1200x" declaredimensions=true alt="UI showing captured point clouds">}}
-
-Example of previously captured IMU data:
-
-{{<imgproc src="/services/slam/offline-mapping-imu-data.png" resize="1200x" declaredimensions=true alt="UI showing captured sensor data">}}
-
-### Create or update a map
-
-From your machine's **Location** page, click **View SLAM library**, and click **Make new map** on the top right and specify a map name or click **Update map** next to an existing map.
-
-1. Enter the **Machine name**, **Camera name**, and optionally the **Movement Sensor name** of the components whose previously captured data you want to use to create or update a map.
-   If your machine has been deleted, you can alternatively specify the [**machine ID**](/reference/apis/fleet/#find-machine-id).
-2. Select the timeframe of the data you'd like to use.
-3. At the bottom, you can see the total number of PCD files and movement sensor data points that will be processed.
-4. Click **Generate map**.
-
-{{<imgproc src="/services/slam/offline-mapping-generate-map.png" resize="1200x" declaredimensions=true alt="UI for creating a new map from captured data">}}
-
-### End a session with previously captured data
-
-Unlike in `Online` mode, you cannot see the map being created while the slam session is in progress, but similar to when creating or updating a map in `Online` mode, you can see that your cloud slam session is in progress from your **Location** page by clicking **View SLAM library**.
-When all the data has been processed (or 45 minutes have passed, whichever occurs first), the map will be saved to your location's **SLAM library**.
-You can see details about the it from your machine's **Location** page by clicking **View SLAM library**.
-
-## Upload a locally built map
-
-If you want to skip using CloudSLAM and build the map on your local machine, the [`cloudslam-wrapper`](https://app.viam.com/module/viam/cloudslam-wrapper) module also allows you to upload a locally built map to your **Location**.
-This lets you share locally built maps across machines in a location easily.
-
-This feature can also be used with SLAM algorithms that CloudSLAM does not currently support. As long as the algorithm implements the SLAM API, you can upload your maps.
-
-### Requirements
-
-- A SLAM algorithm must be configured on the machine. This algorithm does **not** need to be supported by cloudslam to work.
-
-- A location owner API Key or higher. See [Add an API key](/manage/manage/access/) to learn how to create a key!
-
-### Configuration
-
-Add the `cloudslam-wrapper` module to your machine.
-You do **not** need data management configured on the machine.
-Configuring the module will not affect any currently running local SLAM maps.
-Add the following **Attributes**:
-
-```json
-{
-  "slam_service": "<slam-service-name>",
-  "api_key": "<location-api-key>",
-  "api_key_id": "<location-api-key-id>",
-  "organization_id": "<organization_id>",
-  "location_id": "<location_id>",
-  "machine_id": "<machine_id>",
-  "machine_part_id": "<machine_part_id>"
-}
-```
-
-### Upload the map
-
-Navigate to the **CONTROL** tab on your machine's page.
-
-1. Scroll down to the **DoCommand** card
-2. Select your `cloudslam-wrapper` service name from the **Selected component** dropdown
-3. In the **Input** section, enter the following command:
-
-   ```json
-   { "save-local-map": "<MAP-NAME>" }
-   ```
-
-   where `<MAP-NAME>` is the name you want to give the map you wish to generate. 4. Click the **Execute** button.
-   If everything is configured correctly, you should receive a success message.
-   The DoCommand card should look something like:
-
-   ![cloudslam wrapper docommand local upload](/services/slam/cloudslam-module-docommand-local-upload.png)
-
-   Once completed, you can view the final map in the [SLAM library](#the-slam-library-page).
-
-## Attributes
-
-The following attributes are available for `viam:cloudslam-wrapper:cloudslam`
-
-<!-- prettier-ignore -->
-| Name    | Type   | Required?    | Description |
-| ------- | ------ | ------------ | ----------- |
-| `slam_service` | string | **Required** | The name of the SLAM Service on the machine to use with cloudslam. |
-| `api_key` | string | **Required** | An [API key](/manage/manage/access/) with location owner or higher permission. |
-| `api_key_id` | string | **Required** | The associated API key ID with the API key. |
-| `organization_id` | string | **Required** | The organization ID of your [organization](/reference/glossary/#organization). |
-| `location_id` | string | **Required** | The location ID of your [location](/reference/glossary/#location). |
-| `machine_id` | string | **Required** | The machine ID of your [machine](/reference/apis/fleet/#find-machine-id). |
-| `machine_part_id` | string | Optional | The machine part ID of your [machine part](/reference/apis/fleet/#find-machine-id). Used for local package creation and updating mode. |
-| `viam_version` | string | Optional | The version of viam-server to use with CloudSLAM. Defaults to `stable`. |
-| `slam_version` | string | Optional | The version of cartographer to use with CloudSLAM. Defaults to `stable`. |
-| `camera_freq_hz` | float | Optional | The expected capture frequency for your camera/lidar components. Defaults to `5`. |
-| `movement_sensor_freq_hz` | float | Optional | The expected capture frequency for your movement sensor components. Defaults to `20`. |
diff --git a/docs/operate/reference/services/slam/orbslamv3/_index.md b/docs/operate/reference/services/slam/orbslamv3/_index.md
deleted file mode 100644
index b699860de1..0000000000
--- a/docs/operate/reference/services/slam/orbslamv3/_index.md
+++ /dev/null
@@ -1,377 +0,0 @@
----
-title: "ORB-SLAM3 Integrated Library"
-linkTitle: "ORB-SLAM3"
-weight: 70
-type: "docs"
-draft: true
-description: "Configure a SLAM service with the ORB-SLAM3 library."
-tags: ["slam", "services"]
-aliases:
-  - "/services/slam/orbslamv3/"
-  - "/mobility/slam/orbslamv3/"
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: Kat, Jeremy
----
-
-[ORB-SLAM3](https://github.com/UZ-SLAMLab/ORB_SLAM3) performs sparse {{< glossary_tooltip term_id="slam" text="SLAM" >}} using monocular or RGB-D images.
-
-{{% alert title="Tip" color="tip" %}}
-While ORB-SLAM3 does support the use of monocular cameras, for best results it is recommended that you use an RGB-D camera.
-{{% /alert %}}
-
-## Requirements
-
-Install the binary required to use `orbslamv3` on your machine and make it executable by running the following commands according to your machine's architecture:
-
-{{< tabs >}}
-{{% tab name="Linux aarch64" %}}
-
-```sh {class="command-line" data-prompt="$"}
-sudo curl -o /usr/local/bin/orb_grpc_server https://storage.googleapis.com/packages.viam.com/apps/slam-servers/orb_grpc_server-stable-aarch64.AppImage
-sudo chmod a+rx /usr/local/bin/orb_grpc_server
-```
-
-{{< /tab >}}
-{{% tab name="Linux x86_64" %}}
-
-```sh {class="command-line" data-prompt="$"}
-sudo curl -o /usr/local/bin/orb_grpc_server https://storage.googleapis.com/packages.viam.com/apps/slam-servers/orb_grpc_server-stable-x86_64.AppImage
-sudo chmod a+rx /usr/local/bin/orb_grpc_server
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Configuration
-
-How you configure `orbslamv3` depends on whether you want the SLAM service to build your map with data collected live by a [webcam](/operate/reference/components/camera/) or with data provided in a dataset at runtime.
-
-Select from the following modes to obtain the correct instructions to configure the service:
-
-{{% tabs name="Modes"%}}
-{{% tab name="Live Data Collection" %}}
-
-{{% alert title="REQUIREMENTS" color="note" %}}
-
-Running `orbslamv3` in Live Data mode requires a [webcam](/operate/reference/components/camera/).
-The webcam can be installed on a robot, or just held in your hand.
-
-{{% /alert %}}
-
-First, follow these instructions to connect and calibrate your webcam as a component of your machine:
-
-1. [Connect and configure a webcam](/operate/reference/components/camera/webcam/)
-2. [Calibrate a camera](/operate/reference/components/camera/calibrate/)
-
-Now, add the `orbslamv3` service:
-
-{{< tabs name="Add the ORBSLAM3 Service Live">}}
-{{% tab name="Config Builder" %}}
-
-Go to your machine's page.
-Navigate to the **CONFIGURE** tab on your machine's page, and click the **+** button.
-
-Click **Component or service** and add a service with type `slam`, model `orbslamv3`, and a name of your choice.
-
-![adding orbslam3 slam service](/services/slam/add-orbslam-service-ui.png)
-
-Paste the following into the attributes field of your new service:
-
-```json
-{
-  "data_dir": "/home/<YOUR_USERNAME>/<ORBSLAM3_DIR>",
-  "use_live_data": true,
-  "delete_processed_data": true,
-  "sensors": ["<your-webcam-name>"],
-  "config_params": {
-    "mode": "rgbd"
-  }
-}
-```
-
-![adding orbslam3 slam service attributes field](/services/slam/add-orbslam-service-attributes-live.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-Go to your machine's page and navigate to the **CONFIGURE** tab.
-Select the **JSON** mode, then copy/paste the following `"services"` JSON to add to your existing camera configuration:
-
-```json
-// "components": [ ...], YOUR CAMERA COMPONENT
-"services": [
-  {
-    "type": "slam",
-    "name": "<your-service-name>",
-    "model": "orbslamv3",
-    "attributes": {
-      "data_dir": "/home/<YOUR_USERNAME>/<ORBSLAM_DIR>",
-      "use_live_data": true,
-      "delete_processed_data": true,
-      "sensors": [ <your-webcam-name> ],
-      "config_params": {
-        "mode": "rgbd"
-      }
-    }
-  }
-]
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Adjust `"sensors"` to match the name of the webcam you configured.
-
-Now, edit the path specified by `data_dir` to point to a directory on your machine where you want to save the maps and any config files your SLAM service produces.
-
-This directory must be structured as follows:
-
-<pre>
-.
-└──\(<file>ORBSLAM3_DIR</file>)
-    ├── <file>data</file>
-    ├── <file>map</file>
-    └── <file>config</file>
-</pre>
-
-Click through the following tabs to see the usage of each folder in this directory:
-
-{{% tabs name="Folders"%}}
-{{% tab name="/data" %}}
-
-The <file>data</file> folder stores the visual data gathered by your webcam and used for SLAM.
-
-{{% /tab %}}
-{{% tab name="/map" %}}
-
-Whether mapping data is present in <file>data_dir/map</file> at runtime and the attribute `map_rate_sec` determines the SLAM mapping mode:
-
-### Mapping Modes
-
-<!-- prettier-ignore -->
-| Mode | Description | Runtime Dictation |
-| ---- | ----------- | ------- |
-| PURE MAPPING | Generate a new map in file>/map</file>. | No map is found in <file>/map</file>. |
-| UPDATING | Update an existing map with new data. | A map is found in <file>/map</file> + [`map_rate_sec > 0`](#attributes-and-config_params).|
-| LOCALIZING | Localize the robot on an existing map without changing the map itself. | A map is found in <file>/map</file> + [`map_rate_sec = 0`](#attributes-and-config_params). |
-
-{{% /tab %}}
-{{% tab name="/config" %}}
-
-The <file>config</file> folder stores any ORB-SLAM3 specific config files created.
-These are generated at runtime, so there is no need to add anything to this folder.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% alert title="Info" color="info" %}}
-
-If this directory structure is not present at runtime, the SLAM service creates it.
-
-{{% /alert %}}
-
-{{% /tab %}}
-{{% tab name="Dataset" %}}
-
-{{< tabs name="Add the ORBSLAM3 Service with Dataset">}}
-{{% tab name="Config Builder" %}}
-
-Go to your machine's page and navigate to the **CONFIGURE**.
-Then click the **+** button.
-
-Click **Component or service** and add a service with type `slam`, model `orbslamv3`, and a name of your choice:
-
-![adding orbslam3 slam service](/services/slam/add-orbslam-service-ui.png)
-
-Paste the following into the attributes field of your new service:
-
-```json
-{
-  "data_dir": "/home/<YOUR_USERNAME>/<ORBSLAM3_DIR>",
-  "use_live_data": false,
-  "delete_processed_data": false,
-  "config_params": {
-    "mode": "rgbd"
-  }
-}
-```
-
-![adding orbslam3 slam service attributes field](/services/slam/add-orbslam-service-attributes-offline.png)
-
-{{% /tab %}}
-{{% tab name="JSON Template" %}}
-
-Go to your machine's page and navigate to the **CONFIGURE** tab.
-Select the **JSON** mode, then copy/paste the following `"services"` JSON to add to your existing camera configuration:
-
-```json
-// "components": [ ...], YOUR CAMERA COMPONENT
-"services": [
-  {
-    "type": "slam",
-    "name": "<your-service-name>",
-    "model": "orbslamv3",
-    "attributes": {
-      "data_dir": "/home/<YOUR_USERNAME>/<ORBSLAM3_DIR>",
-      "use_live_data": false,
-      "delete_processed_data": false,
-      "config_params": {
-        "mode": "rgbd"
-      }
-    }
-  }
-]
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-Now, edit the path specified by `data_dir` to point to a directory on your machine where you want to save the maps and any config files your SLAM service produces.
-
-This directory must be structured as follows:
-
-<pre>
-.
-└──\(<file>ORBSLAM3_DIR</file>)
-    ├── <file>data</file>
-    ├── <file>map</file>
-    └── <file>config</file>
-</pre>
-
-Click through the following tabs to see the usage of each folder in this directory:
-
-{{% tabs name="Folders 2"%}}
-{{% tab name="/data" %}}
-
-As you are configuring SLAM to run without live data collection, you need to make sure the <file>data</file> folder contains visual data at runtime for the service to generate a <map>map</file> from.
-
-If you do not already have a dataset from running SLAM live or another dataset you want to use as <file>/data</file>, follow these instructions to use a sample dataset from Viam's lab:
-
-1. Download Viam's [lab dataset](https://storage.googleapis.com/viam-labs-datasets/viam-office-hallway-1-rgbd.zip).
-
-2. Copy the zipped file to the machine running `viam-server` and unzip it.
-   For example:
-
-   ```sh {class="command-line" data-prompt="$"}
-   scp ~/Downloads/viam-office-hallway-1-rgbd.zip <YOUR_USERNAME>@<YOUR_MACHINE>.local:~/.
-   unzip viam-office-hallway-1-rgbd.zip
-   ```
-
-3. Rename the unzipped folder to <file>data</file> and place inside of the folder at <file>data_dir</file>. For example:
-
-   ```sh {class="command-line" data-prompt="$"}
-   cd /home/<YOUR_USERNAME>/<ORBSLAM3_DIR>
-   mv ~/Downloads/viam-office-hallway-1-rgbd data/
-   ```
-
-{{% /tab %}}
-{{% tab name="/map" %}}
-
-Whether mapping data is present in <file>data_dir/map</file> at runtime and the attribute `map_rate_sec` determines the SLAM mapping mode:
-
-### Mapping Modes
-
-<!-- prettier-ignore -->
-| Mode | Description | Runtime Dictation |
-| ---- | ----------- | ------- |
-| PURE MAPPING | Generate a new map. | No map is found in <file>/map</file>. |
-| UPDATING | Update an existing map with new data. | A map is found in <file>/map</file> + [`map_rate_sec > 0`](#attributes-and-config_params).|
-| LOCALIZING | Localize the robot on an existing map without changing the map itself. | A map is found in <file>/map</file> + [`map_rate_sec = 0`](#attributes-and-config_params). |
-
-{{% /tab %}}
-{{% tab name="/config" %}}
-
-The <file>config</file> folder stores ORB-SLAM3 specific config files.
-These are generated at runtime, so there is no need to adjust this folder.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Attributes and `config_params`
-
-{{% tabs name="Attributes"%}}
-{{% tab name="Attributes" %}}
-
-<!-- prettier-ignore -->
-| Name | Data Type | Required? | Description |
-| ---- | --------- | --------- | ----------- |
-| `data_dir` | string | **Required** | Path to the directory used for saving input <file>/data</file> and output <file>/map</file> visualizations. |
-| `sensors` | string[] | **Required** | Names of any configured [webcams](/operate/reference/components/camera/) providing data to the SLAM service. |
-| `use_live_data` | bool | **Required** | <p>Whether to run in Live Data Collection mode.</p> <ul> `true`: Use data collected live by `sensors`to generate <file>/map</file>. </ul><ul>`false`: Use a dataset provided in <file>data_dir/data</file> to generate <file>/map</file>. </ul> |
-| `map_rate_sec` | int | Optional | Map generation rate for saving current state *(seconds)*. <ul> Default: `60`. </ul> |
-| `data_rate_msec` | int | Optional | Data generation rate for collecting sensor data to feed to SLAM *(milliseconds)*. <ul>Default: `200`.</ul> |
-| `port` | string | Optional | Port for SLAM gRPC server. If running locally, this should be in the form "localhost:<PORT>". If no value is specified a random available port is assigned. |
-| `delete_processed_data` | bool | Optional | <p>Setting this to `true` helps to reduce the amount of memory required to run SLAM.</p> <ul> `true`: sensor data is deleted after the SLAM algorithm has processed it. </ul><ul> `false`: sensor data is not deleted after the SLAM algorithm has processed it. </ul> |
-| `config_params` |  map[string] string | Optional | Parameters to fine-tune the algorithm `orbslamv3` uses. |
-
-{{% alert title="Caution" color="caution" %}}
-
-- If `use_live_data: true`, `delete_processed_data: true` by default.
-- If `use_live_data: false`, `delete_processed_data: false` by default.
-
-Setting `delete_processed_data: true` and `use_live_data: false` is invalid and will result in an error.
-{{% /alert %}}
-
-{{% /tab %}}
-{{% tab name="config_params" %}}
-
-Adjust these parameters to fine-tune the algorithm `orbslamv3` uses:
-
-<!-- prettier-ignore -->
-| Parameter | Description | Required? | Default Value |
-| -------------- | ----------- | --------- | ------------- |
-| `mode` | `rgbd` or `mono` | **Required** | No default |
-| `debug` | Boolean specifying if the service should be run in debug mode. Affects log output. | Optional | `false` |
-| `orb_n_features` | Number of features per image. | Optional | `1250` |
-| `orb_scale_factor` | Scale factor between levels in the scale pyramid. | Optional | `1.2` |
-| `orb_n_levels` | Number of levels in the scale pyramid. | Optional | `8` |
-| `orb_n_ini_th_fast` | Initial FAST threshold. | Optional | `20` |
-| `orb_n_min_th_fast` | Lower threshold if no corners detected. | Optional | `7` |
-| `stereo_th_depth` | Number of stereo baselines used to classify a point as close or far. Close and far points are treated differently in several parts of the stereo SLAM algorithm. | Optional | `40` |
-| `depth_map_factor` | Factor to transform the depth map to real units. | Optional | `1000` |
-| `stereo_b` | Stereo baseline in meters. | Optional | `0.0745` |
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## View the Map
-
-After saving your config, head over to the **CONTROL** tab and click on the dropdown menu matching the `name` of the service you created.
-
-Change the **Refresh frequency** to your desired frequency.
-If in Live Data mode, move your webcam around slowly.
-Watch a map start to appear.
-
-{{% alert title="Tip" color="tip" %}}
-It might take a couple of minutes before a map is displayed.
-Keep moving the camera slowly within your space and wait for the map to visualize.
-{{% /alert %}}
-
-## Troubleshooting
-
-### Known Issues
-
-#### "CURRENTLY NO MAP POINTS EXIST"
-
-This issue has a couple of potential causes.
-
-![error getting SLAM map](/services/slam/01_slam_tutorial_no_map_points.png)
-
-First, it might take a few minutes for ORB-SLAM3 to create an initial map after starting up.
-In both live and offline mode, this might mean that you have to wait a little while before you can see a map on the UI.
-
-Second, map generation depends on the quality of the dataset.
-For consecutive images, the camera's focus should not be moved too far from that of the previous image, and images should contain enough details that can be detected by ORB-SLAM3.
-Images from a white wall for example will not successfully generate a map.
-Try to point the camera into areas that contain a lot of information, such as objects, window frames, and similar.
-
-In live mode, it helps to move the camera around slowly, so that consecutive images containing similar items can be matched to each other.
-
-In offline mode, it can be difficult to determine the quality of the dataset.
-If no map can be generated using the offline dataset, a new dataset should be generated.
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
diff --git a/docs/operate/reference/sessions.md b/docs/operate/reference/sessions.md
deleted file mode 100644
index 24cc077f40..0000000000
--- a/docs/operate/reference/sessions.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: "Session management with Viam's client SDKs"
-linkTitle: "Session management"
-weight: 70
-type: "docs"
-layout: "empty"
-canonical: "/dev/reference/apis/sessions/"
----
diff --git a/docs/operate/reference/slam-background.md b/docs/operate/reference/slam-background.md
deleted file mode 100644
index 4c614e6f4a..0000000000
--- a/docs/operate/reference/slam-background.md
+++ /dev/null
@@ -1,280 +0,0 @@
----
-title: "SLAM service background"
-linkTitle: "SLAM technical"
-weight: 70
-type: "docs"
-draft: true
-description: "Background and technical information for the Simultaneous Localization And Mapping (SLAM) service, its configuration, its functionality, and its interfaces."
-tags: ["slam", "services"]
-aliases:
-  - "/internals/slam"
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
-# SMEs: Jeremy, Kat
----
-
-{{< glossary_tooltip term_id="slam" text="SLAM" >}} is an important area of ongoing research in robotics, particularly for mobile applications such as drones, boats, and rovers.
-At Viam, we want to offer our users an easy-to-use, intuitive method for interfacing with various SLAM algorithms that may be useful in their mission.
-
-As of June 01, 2022, we support the following SLAM libraries:
-
-[ORBSLAM3](https://github.com/UZ-SLAMLab/ORB_SLAM3)
-
-## Current Architecture
-
-The SLAM service in the RDK (located in /rdk/service/slam) is a wrapper for the C++ SLAM libraries mentioned above.
-It has three roles, interface with an executable C++ binary of the chosen library, start up a data process (if desired), and to pass GRPC requests/responses between servers.
-
-<img src="/services/slam-service-arch.png" alt="Flow diagram of the SLAM service architecture."/>
-
-### Data Generation
-
-Coming soon!
-
-TODO: Do we want to discuss that RGBD cameras produce a rgb and depth folder inside data?
---> Add an explanation of what kind of subfolders are created for the "mono" case and the "rgbd" case (that is rgb, and rgbd + depth).
-Elaborate on what the user should keep in mind when creating & integrating their own slam libraries, and whether or not it is important for them to document the subfolders that are created.
-
-<pre>
-.
-└──\(The Directory Defined in Config)
-    ├── data
-    ├── map
-    └── config
-</pre>
-
-The implemented SLAM libraries rely on the filename to know when this data was generated and what sensor was used to collect it.
-The format for the timestamp is currently (10 Oct 2022) `"2006-01-02T15_04_05.0000"`.
-Please note, this will be updated soon to align with the conventions used by the datamanager service.
-
-### Interfacing with the C++ Binary
-
-The SLAM binaries used are stored in <file>/usr/local/bin</file>.
-If you wish to use an updated version, copy the new binary into this directory.
-If you use an identical name for this new binary, you will not need to change the RDK SLAM code. If you use a new name for the binary, then it must be relinked in <file>services/slam/slamlibraries.go</file> in the BinaryLocation metadata.
-Note: a new binary with a different name can be stored anywhere as long as it is included in your PATH.
-
-## Machine Config
-
-```json
-"services": [
-  {
-    "attributes": {
-      "algorithm": "cartographer",
-      "data_dir": "<path_to_folder>",
-      "sensors": ["rplidar"],
-      "config_params": {
-        "mode": "2d"
-      },
-      "map_rate_sec": 60,
-      "data_rate_ms": 200,
-      "input_file_pattern": "1:1000:1"
-    },
-    "name": "test",
-    "type": "slam"
-  }
-]
-```
-
-### Required Attributes
-
-**algorithm** (string): Name of the SLAM library/algorithm to be used.
-Current options are cartographer or orbslamv3.
-
-**data_dir** (string): This is the data directory used for saving input sensor/map data and output maps/visualizations.
-It has an architecture consisting of three internal folders, config, data and map.
-If these have not been provided, they will be created by the SLAM service.
-The data in the data directory also dictate what type of SLAM will be run:
-
-- If no map is provided in the data folder, the SLAM algorithm will generate a new map using all the provided data (PURE MAPPING MODE)
-
-- If a map is found in the data folder, it will be used as a priori information for the SLAM run and only data generated after the map will be used.
-  (PURE LOCALIZATION MODE/UPDATING MODE)
-
-- If a map_rate_sec is provided, then the system will overlay new data on any given map (PURE MAPPING MODE/UPDATING MODE)
-
-**Sensors** (string[]): Names of sensors which are input to SLAM
-
-### Optional Attributes
-
-**map_rate_sec** (int): Map generation rate for saving current state (in seconds).
-The default value is 60.
-If an integer is less or equal to 0 then SLAM is run in localization mode.
-
-**data_rate_ms** (int): Data generation rate for collecting sensor data to be fed into SLAM (in milliseconds).
-The default value is 200.
-If 0, no new data is sent to the SLAM algorithm.
-
-**input_file_pattern** (string): File glob describing how to ingest previously saved sensor data.
-Must be in the form X:Y:Z where Z is how many files to skip while iterating between the start index, X and the end index Y.
-
-{{% alert title="Info" color="info" %}}
-X and Y are the file numbers since the most recent map data package in the data folder.
-If nil, includes all previously saved data.
-{{% /alert %}}
-
-**port** (string): Port for SLAM gRPC server.
-If running locally, this should be in the form `localhost:<PORT>`.
-If no value is given a random available port will be assigned.
-
-**config_params** (map[string] string): Parameters specific to the
-inputted SLAM library.
-
-### SLAM Library Attributes
-
-`config_params` is a catch-all attribute for parameters that are unique to the in-use SLAM library.
-`config_params` often deal with the internal algorithms being run and will affect such aspects as submap size, update rate, and details on how to perform feature matching, to name a few.
-
-You can find details on which inputs you can include for the available libraries in the following sections.
-
-#### OrbSLAM
-
-OrbSLAM can perform sparse SLAM using monocular or RGB-D images (not stereo); this must be specified in the config_params (as "mono" or "rgbd").
-In addition the follow variables can be added to fine-tune cartographer's algorithm, all of which are optional:
-
-<table>
-    <tr>
-        <th style="width:25%">Parameter Mode</th>
-        <th style="width:70%">Description - The Type of SLAM to Use</th>
-        <th>Default:<br>
-        RGBD, Mono</th>
-    </tr>
-    <tr>
-        <td>orb_n_features</td>
-        <td>ORB parameter. Number of features per image</td>
-        <td>1200</td>
-    </tr>
-    <tr>
-        <td>orb_scale_factor</td>
-        <td>ORB parameter. Scale factor between levels in the scale
-         pyramid</td>
-        <td>1.2</td>
-    </tr>
-    <tr>
-        <td>orb_n_levels</td>
-        <td>ORB parameter. Number of levels in the scale pyramid</td>
-        <td>8</td>
-    </tr>
-    <tr>
-        <td>orb_n_ini_th_fast</td>
-        <td>ORB parameter. Initial FAST threshold</td>
-        <td>20</td>
-    </tr>
-    <tr>
-        <td>orb_n_min_th_fast</td>
-        <td>ORB parameter. Lower threshold if no corners detected</td>
-        <td>7</td>
-</table>
-
-## Hardware Requirements
-
-Forthcoming
-
-## Installation
-
-### Using an App Image
-
-Coming soon!
-
-### Manual Installation
-
-Perform a git clone on the SLAM repository using the recursive install flag to allow the sub packages to be downloaded as well.
-
-```sh {class="command-line" data-prompt="$"}
-git clone --recurse-submodules git@github.com:viamrobotics/slam.git
-```
-
-#### ORBSLAM3 Setup
-
-This setup documents the current process for getting ORBSLAM3 working locally on a Raspberry Pi.
-
-##### Dependencies
-
-The following are the required dependencies for building and running ORBSLAM3.
-In addition you should ensure the most recent version of the orbslam submodule is located in your directory with
-
-```sh {class="command-line" data-prompt="$"}
-git submodule update --init --recursive
-```
-
-###### Pangolin - to setup run the following
-
-```sh {class="command-line" data-prompt="$"}
-git clone --recursive https://github.com/stevenlovegrove/Pangolin.git
-cd Pangolin
-./scripts/install_prerequisites.sh recommended
-mkdir build && cd build
-cmake ..
-make -j4
-sudo make install
-```
-
-###### OpenCV
-
-```{class="command-line" data-prompt="$"}
-sudo apt install libopencv-dev
-```
-
-###### Eigen
-
-```{class="command-line" data-prompt="$"}
-sudo apt install libeigen3-dev
-```
-
-###### gRPC
-
-To setup gRPC, use the following command:
-
-```{class="command-line" data-prompt="$"}
-cd \~/slam/slam-libraries
-mae pull-rdk
-```
-
-This command pulls a minimal copy of rdk and build c++ gRPC files off of our proto.
-
-###### Other Dependencies
-
-```{class="command-line" data-prompt="$"}
-sudo apt install libssl-dev
-sudo apt-get install libboost-all-dev
-```
-
-##### Building ORBSLAM3
-
-To build ORBSLAM3 run
-
-```{class="command-line" data-prompt="$"}
-cd \~/slam/slam-libraries/viam-orb-slam
-./build_orbslam.sh
-```
-
-Should the code fail the initial setup (your Pi freezes and requires a restart), change the _make -j\`nproc\`_ flags into _make -j2_
-
-After building, use the following command to move the binary to `/usr/local/bin`:
-
-```{class="command-line" data-prompt="$"}
-sudo cp bin/orb_grpc_server /usr/local/bin
-```
-
-In addition, make sure the binary is added in SLAMlibraries.go for ORBSLAM3 in rdk.
-
-Lastly, move the vocabulary file into your data directory.
-You must do this whenever a new data directory will be used.
-
-```{class="command-line" data-prompt="$"}
-cp ORB_SLAM3/Vocabulary/ORBvoc.txt ~/YOUR_DATA_DIR/config
-```
-
-## Usage
-
-### Creating an initial map
-
-Coming soon!
-
-### Pure localization on a priori map
-
-Coming soon!
-
-### Updating an a priori map
-
-Coming soon!
diff --git a/docs/operate/reference/viam-micro-server/_index.md b/docs/operate/reference/viam-micro-server/_index.md
deleted file mode 100644
index 7be6825f87..0000000000
--- a/docs/operate/reference/viam-micro-server/_index.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: "The Micro-RDK and viam-micro-server"
-linkTitle: "viam-micro-server"
-weight: 40
-type: docs
-images: ["/installation/thumbnails/esp32-espressif.png"]
-imageAlt: "E S P 32 - espressif"
-description: "Set up the Espressif ESP32 for development with `viam-micro-server`."
-date: "2024-09-03"
-aliases:
-  - /architecture/viam-micro-server/
-# updated: ""  # When the content was last entirely checked
-# SMEs: Nicolas M., Gautham V., Andrew M.
----
-
-[The Micro-RDK](https://github.com/viamrobotics/micro-rdk/) is the lightweight version of Viam's [Robot Development Kit (RDK)](https://github.com/viamrobotics/rdk/tree/main) designed for embedded systems (ESP32 microcontrollers) that do not have the resources to run the fully-featured [`viam-server`](/operate/reference/viam-server/).
-
-Microcontrollers do not have full operating systems like single-board computers and general-purpose computers.
-As a result, microcontrollers only run one program at a time.
-To change the logic that runs on a microcontroller, you must flash the microcontroller with new firmware.
-
-`viam-micro-server` is the pre-built firmware built from the Micro-RDK and a [default set](/operate/install/setup-micro/#about-esp32-microcontroller-setup) of {{< glossary_tooltip term_id="module" text="modules" >}}, provided as a quick starting point.
-For most use cases, you will [build your own firmware](/operate/install/setup-micro/#build-and-flash-custom-firmware) from the Micro-RDK instead of using `viam-micro-server`.
-
-## Hardware requirements
-
-{{% readfile "/static/include/micro-rdk-hardware.md" %}}
-
-## Support
-
-[Client API](/reference/apis/) usage with the Micro-RDK currently supports the following {{< glossary_tooltip term_id="resource" text="resources" >}}:
-
-{{< cards >}}
-{{% relatedcard link="/reference/apis/components/base/" %}}
-{{% relatedcard link="/reference/apis/components/board/" %}}
-{{% relatedcard link="/reference/apis/components/camera/" %}}
-{{% relatedcard link="/reference/apis/components/encoder/" %}}
-{{% relatedcard link="/reference/apis/components/movement-sensor/" %}}
-{{% relatedcard link="/reference/apis/components/motor/" %}}
-{{% relatedcard link="/reference/apis/components/sensor/" %}}
-{{% relatedcard link="/reference/apis/components/servo/" %}}
-{{% relatedcard link="/reference/apis/components/generic/" %}}
-{{% relatedcard link="/reference/apis/services/data/" %}}
-{{< /cards >}}
-
-## Next steps
-
-To use the Micro-RDK with existing modules, follow the ESP32 setup guide.
-To create your own modules, follow the Modules for ESP32 guide.
-
-{{< cards >}}
-{{% card link="/operate/install/setup-micro/" %}}
-{{% card link="/operate/modules/advanced/micro-module/" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/viam-server/_index.md b/docs/operate/reference/viam-server/_index.md
deleted file mode 100644
index 0547b67c83..0000000000
--- a/docs/operate/reference/viam-server/_index.md
+++ /dev/null
@@ -1,472 +0,0 @@
----
-title: "viam-server"
-linkTitle: "viam-server"
-weight: 31
-type: "docs"
-description: "viam-server is the open-source, on-machine portion of the Viam platform."
-tags: ["server", "rdk"]
-aliases:
-  - "/product-overviews/rdk"
-  - "/build/program/rdk"
-  - /internals/rdk/
-  - /architecture/rdk/
-  - /architecture/viam-server/
-  - /internals/local-configuration-file/
-  - /operate/reference/viam-server/local-configuration-file/
-date: "2022-01-01"
-# updated: ""  # When the content was last entirely checked
----
-
-The `viam-server` executable runs on a computer and manages hardware, software, and data for a machine.
-`viam-server` is built from the open-source [Robot Development Kit (RDK)](https://github.com/viamrobotics/rdk).
-If you are working with microcontrollers, [`viam-micro-server`](/operate/reference/viam-micro-server/) is a lightweight version of `viam-server` which can run on resource-limited embedded systems that cannot run the fully-featured `viam-server`.
-
-To use Viam with a machine, you create a configuration specifying which hardware and software the machine consists of.
-`viam-server` then manages and runs the drivers for the configured {{< glossary_tooltip term_id="resource" text="resources" >}}.
-
-Overall, `viam-server` manages:
-
-- [Communication](#communication)
-- [Start-up](#start-up)
-- [Reconfiguration](#reconfiguration)
-- [Maintenance windows](#maintenance-window)
-- [Shutdown](#shutdown)
-- [Logging](#logging)
-
-## Communication
-
-`viam-server` handles all {{< glossary_tooltip term_id="grpc" text="gRPC" >}} and {{< glossary_tooltip term_id="webrtc" >}} communication for connecting machines to the cloud or for connecting to other parts of your machine.
-
-All communication happens securely over HTTPS using secret tokens that are in the machine's config.
-
-## Lifecycle
-
-### Start-up
-
-The machine setup steps copy your machine's credentials to your machine.
-When you turn on your machine, `viam-server` starts up and uses the provided credentials to fetch its configuration from Viam.
-
-`viam-server` ensures that any configured {{< glossary_tooltip term_id="module" text="modules" >}}, {{< glossary_tooltip term_id="resource" text="built-in resources" >}} and {{< glossary_tooltip term_id="modular-resource" text="modular resources" >}} are loaded on startup.
-`viam-server` handles [dependency](/operate/modules/advanced/dependencies/) management between resources.
-
-After start-up, `viam-server` manages:
-
-- the connections to hardware,
-- the running services, and
-- the {{< glossary_tooltip term_id="module" text="modules" >}} that provide the {{< glossary_tooltip term_id="modular-resource" text="modular resources" >}}.
-
-### Reconfiguration
-
-Once the machine has a configuration, it caches it locally (in a file at <FILE>~/.viam/cached_cloud_config\_\<PART-ID\>.json</FILE>) and can use the config for up to 60 days.
-Since the configuration is cached locally, your machine does not need to stay connected to Viam after it has obtained its configuration file.
-
-If it is online, the machine automatically checks for new configurations every 15 seconds.
-When you or your collaborators change the configuration of a machine, `viam-server` automatically synchronizes the configuration to your machine and updates the running resources.
-
-Reconfiguration of individual resources happens concurrently if there are no configured dependencies for any resources.
-If there are configured dependencies, resources are reconfigured in groups.
-
-You can see configuration changes made by yourself or by your collaborators by selecting **History** on the right side of your machine part's card on the **CONFIGURE** tab.
-You can also revert to an earlier configuration from the History tab.
-
-{{% hiddencontent %}}
-If you want to force a reconfiguration of a resource, you can click the **Disable** button in the resource menu, save, and then re-enable the resource.
-
-Alternatively, if you are having issues with a module, try the **Restart module** button in the module menu.
-{{% /hiddencontent %}}
-
-### Maintenance window
-
-There are a few updates that may make your machine temporarily unavailable:
-
-- [`viam-agent` updating itself](/manage/reference/viam-agent/#version-control)
-- [`viam-agent` updating `viam-server`](/manage/reference/viam-agent/#update-or-downgrade-viam-server-with-viam-agent)
-- configuration updates
-
-To avoid performing these updates until your machine is ready for maintenance, you can define a maintenance window.
-A maintenance window consists of one or multiple conditions that determine if maintenance is currently allowed.
-To configure a maintenance window, you need to create a sensor that returns true when your maintenance conditions are met and false otherwise.
-
-{{< tabs >}}
-{{% tab name="Builder UI" %}}
-
-To configure a maintenance window, click the **+** icon next to your {{< glossary_tooltip term_id="part" text="machine part" >}} in the left-hand menu of the **CONFIGURE** tab and select **Maintenance window**.
-
-In the new panel, specify the name of the sensor and the key for the value to be used to determine when maintenance is allowed.
-
-{{% /tab %}}
-{{% tab name="JSON" %}}
-
-To configure a maintenance window, add the following configuration to your machine's JSON configuration:
-
-```json
-// components: [ ... ],
-// services: [ ... ],
-maintenance : {
-   "sensor_name" : string,
-   "maintenance_allowed_key" : string
-}
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-<!-- prettier-ignore -->
-| Attribute | Type | Required? | Description |
-| --------- | ---- | --------- | ----------- |
-| `sensor_name` | string | **Required** | The full name of the sensor that provides the information if it is safe to update a machine's configuration. For example `rdk:component:sensor/sensor1`. |
-| `maintenance_allowed_key` | string | **Required** | The key of the key value pair for the reading returned by the sensor. |
-
-### Shutdown
-
-During machine shutdown, `viam-server` handles modular resource instances similarly to built-in resource instances - it signals them for shutdown in topological (dependency) order.
-
-## Logging
-
-Log messages appear under the [**LOGS** tab](/manage/troubleshoot/troubleshoot/#check-logs) for a machine.
-
-The default log level for `viam-server` and any running resources is `"Info"`.
-Logs are stored for 30 days before they are deleted.
-
-If you need more logs for an individual resource, click **Enable debug logs** in the **...** menu on the resource.
-
-To set other log levels for individual resources, add the `log_configuration` option to the resource's JSON configuration:
-
-```json
-"log_configuration": {
-    "level": "Debug"
-},
-"attributes": { ... }
-```
-
-For modular resources, you must instead set the `log_level` attribute on the module itself:
-
-```json {class="line-numbers linkable-line-numbers" data-line="3"}
-"module_id": "viam:raspberry-pi",
-"version": "1.9.0",
-"log_level":  "debug"
-```
-
-Alternatively, you can configure logs for all machine resources, inside your machine config.
-To specify the log level for a specific resource, add the `log` field to your machine config:
-
-For example:
-
-```json
-"components": [ ... ]
-"log": [
-    {
-    "pattern": "rdk.components.arm",
-    "level": "debug",
-    }, {
-    "pattern": "rdk.services.*",
-    "level": "debug",
-    }, {
-    "pattern": "<module-name>",
-    "level": "debug",
-    }
-]
-```
-
-<!-- prettier-ignore -->
-| Attribute | Description |
-| --------- | ----------- |
-| `pattern` | A regular expression (regex) pattern matching one or more resources. |
-| `level` | The log level: `"debug"`, `"info"`, `"warn"`, or `"error"`. |
-
-Patterns are processed from top to bottom.
-If multiple patterns apply, the last pattern to be processed will apply.
-If log configurations are applied at a resource level using the `log_configuration` field, these take precedence over log levels applied in the `log` field of the machine configuration.
-
-{{% expand "Click to view full configuration example" %}}
-
-```json {class="line-numbers linkable-line-numbers" data-line="10-18"}
-{
-  "components": [
-    {
-      "name": "camera1",
-      "api": "rdk:component:camera",
-      "model": "fake"
-    }
-  ],
-  "services": [],
-  "log": [
-    {
-      "pattern": "rdk.resource_manager",
-      "level": "info"
-    },
-    {
-      "pattern": "rdk.resource_manager.*",
-      "level": "debug"
-    }
-  ]
-}
-```
-
-{{% /expand%}}
-
-### Disable log deduplication
-
-By default, `viam-server` deduplicates log messages that are deemed noisy.
-A log is deemed noisy if it has been output 3 times in the past 10 seconds.
-
-To disable log deduplication, set `disable_log_deduplication` in your machine's configuration:
-
-```json
-"disable_log_deduplication": true
-```
-
-{{% expand "Click to view full configuration example" %}}
-
-```json {class="line-numbers linkable-line-numbers" data-line="10"}
-{
-  "components": [
-    {
-      "name": "camera1",
-      "api": "rdk:component:camera",
-      "model": "fake"
-    }
-  ],
-  "services": [],
-  "disable_log_deduplication": true
-}
-```
-
-{{% /expand%}}
-
-### Delete machine logs
-
-You cannot delete machine logs.
-If your machine has generated a large amount of logs and you are concerned about the cost, you can:
-
-1. Copy the machine's configuration to a new machine.
-2. Delete the old machine.
-
-If you delete a machine you will not be charged for the remainder of the 30 days until logs from that machine are deleted.
-
-### Debugging
-
-You can enable debug level logs in two ways:
-
-- Start `viam-server` with the `-debug` option.
-- Add `"debug": true` to the machine's configuration:
-
-  ```json
-  {
-    "debug": true,
-    "components": [{ ... }]
-  }
-  ```
-
-Enabling debug level logs will take precedence over all logging configuration set using the `log` field on a machine or the `log_configuration` field on a resource.
-
-## Core options
-
-<!-- prettier-ignore -->
-| Option | Description |
-| ------ | ----------- |
-| `-allow-insecure-creds` | Allow connections to send credentials over plaintext. |
-| `-config <filename>` | The machine configuration file containing machine cloud credentials or a full configuration. |
-| `-cpuprofile string` | Write CPU profile to file. |
-| `-debug` | Enable debug level logs. |
-| `-disable-mdns` | Disable server discovery through multicast DNS. |
-| `-dump-resources <filepath>` | Dump all resource registrations as JSON to the provided file path. |
-| `-ftdc` | Enable fulltime data capture for diagnostics. Default: `true`. |
-| `-log-file <filename>` | Write logs to a file with log rotation. |
-| `-network-check` | Only runs normal network checks. |
-| `-no-tls` | Starts an insecure HTTP server without TLS certificates even if one exists. |
-| `-output-telemetry` | Print out telemetry data (metrics and spans). |
-| `-reveal-sensitive-config-diffs` | Show config diffs. |
-| `-shareddir <directory-name>` | The location of the static web assets. |
-| `-untrusted-env` | Disable processes and shell from running in an untrusted environment. |
-| `-version` | Print version. |
-| `-webprofile` | Include profiler in HTTP server. |
-| `-webrtc` | Force WebRTC connections instead of direct connections. Default: `true`. |
-
-## Install `viam-server` without the web UI
-
-{{% alert title="Tip" color="tip" %}}
-The recommended way to install `viam-server` and connect your machine to Viam is covered in the [Set up a computer or SBC guide](/operate/install/setup/).
-{{% /alert %}}
-
-If you need to install `viam-server` without the web UI, you can run the following commands.
-
-{{< tabs >}}
-{{% tab name="Linux (Aarch64)" %}}
-{{< tabs >}}
-{{% tab name="Install manually" %}}
-
-```bash {class="line-numbers linkable-line-numbers"}
-curl https://storage.googleapis.com/packages.viam.com/apps/viam-server/viam-server-stable-aarch64.AppImage -o viam-server
-```
-
-Next, to make the `viam-server` executable and install as a system service, run the following command:
-
-```bash {class="line-numbers linkable-line-numbers"}
-chmod 755 viam-server && sudo ./viam-server --aix-install
-```
-
-The `viam-server` binary is installed at <FILE>/usr/local/bin/viam-server</FILE>.
-
-{{% /tab %}}
-{{% tab name="Install using viam-agent" %}}
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-sudo /bin/sh -c "$(curl -fsSL https://storage.googleapis.com/packages.viam.com/apps/viam-agent/install.sh)"
-```
-
-The `viam-agent` and `viam-server` binaries are installed at <FILE>/opt/viam/bin/viam-server</FILE>.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /tab %}}
-{{% tab name="Linux (x86_64)" %}}
-
-{{< tabs >}}
-{{% tab name="Install manually" %}}
-
-```bash {class="line-numbers linkable-line-numbers"}
-curl https://storage.googleapis.com/packages.viam.com/apps/viam-server/viam-server-stable-x86_64.AppImage -o viam-server
-```
-
-Next, to make the `viam-server` executable and install as a system service, run the following command:
-
-```bash {class="line-numbers linkable-line-numbers"}
-chmod 755 viam-server && sudo ./viam-server --aix-install
-```
-
-The `viam-server` binary is installed at <FILE>/usr/local/bin/viam-server</FILE>.
-
-{{% /tab %}}
-{{% tab name="Install using viam-agent" %}}
-
-```sh {id="terminal-prompt" class="command-line" data-prompt="$"}
-sudo /bin/sh -c "$(curl -fsSL https://storage.googleapis.com/packages.viam.com/apps/viam-agent/install.sh)"
-```
-
-The `viam-agent` and `viam-server` binaries are installed at <FILE>/opt/viam/bin/viam-server</FILE>.
-
-{{% /tab %}}
-{{< /tabs >}}
-{{% /tab %}}
-{{% tab name="macOS" %}}
-
-```bash {class="line-numbers linkable-line-numbers"}
-brew tap viamrobotics/brews && brew install viam-server
-```
-
-The `viam-server` binary is installed at <FILE>/opt/homebrew/bin/viam-server</FILE>.
-
-The brew installation of `viam-server` CANNOT be run as a system service in the
-background. If you would like to run `viam-server` in the background, install
-[`viam-agent`](/manage/reference/viam-agent/) instead.
-
-{{% /tab %}}
-{{% tab name="Windows Subsystem for Linux (WSL)" %}}
-
-```bash {class="line-numbers linkable-line-numbers"}
-curl https://storage.googleapis.com/packages.viam.com/apps/viam-server/viam-server-stable-x86_64 -o viam-server && chmod 755 viam-server
-```
-
-{{% /tab %}}
-{{% tab name="Windows native" %}}
-
-Manual installation is not available for native Windows; you must download the [Viam Agent installer](https://storage.googleapis.com/packages.viam.com/apps/viam-agent/viam-agent-windows-installer.exe).
-
-The `viam-agent` and `viam-server` binaries are installed at <FILE>C:\opt\viam\cache</FILE>.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-### Install a specific version of `viam-server`
-
-In some cases, you may need to install an older version of `viam-server`.
-
-{{< tabs name="Install specific version of viam-server" >}}
-{{% tab name="Linux" %}}
-
-For Linux systems, the recommended approach to install an older version is to build from source:
-
-```sh {class="command-line" data-prompt="$"}
-# Clone the RDK repository
-git clone https://github.com/viamrobotics/rdk.git
-
-# Change to the RDK directory
-cd rdk
-
-# Check out a specific version tag (replace v0.46.0 with your desired version)
-git checkout v0.46.0
-
-# Build the server
-make server
-
-# The binary will be available in the bin directory for your architecture
-cd bin/Linux-amd64  # or Linux-arm64 for ARM-based systems
-```
-
-You can then run the server directly:
-
-```sh {class="command-line" data-prompt="$"}
-sudo ./viam-server -config /path/to/your/config.json
-```
-
-{{% /tab %}}
-{{% tab name="macOS" %}}
-
-There are two approaches to installing an older version of `viam-server` on macOS:
-
-### Option 1: Build from source
-
-The most reliable way to install a specific version of `viam-server` is to clone the RDK repository at a specific tag and build it yourself:
-
-```sh {class="command-line" data-prompt="$"}
-# Clone the RDK repository
-git clone https://github.com/viamrobotics/rdk.git
-
-# Change to the RDK directory
-cd rdk
-
-# Check out a specific version tag (replace v0.46.0 with your desired version)
-git checkout v0.46.0
-
-# Build the server
-make server
-
-# The binary will be available in the bin directory for your architecture
-cd bin/Darwin-arm64  # Use the folder matching your architecture
-```
-
-You can then run the server directly:
-
-```sh {class="command-line" data-prompt="$"}
-./viam-server -config /path/to/your/config.json
-```
-
-### Option 2: Use an older version of the Homebrew tap
-
-If you've already installed `viam-server` with Homebrew, you can try checking out an older version of the Viam Homebrew tap:
-
-```sh {class="command-line" data-prompt="$"}
-# Navigate to the Homebrew tap directory
-cd /opt/homebrew/Library/Taps/viamrobotics/homebrew-brews/
-
-# Check out an older version of the tap
-git checkout <older-commit-hash>
-
-# Reinstall viam-server
-brew reinstall viam-server
-```
-
-Note that this method may not work for versions that are too old, as Homebrew doesn't officially support installing older versions of dependencies. If the version you need is significantly older, building from source (Option 1) is recommended.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Next steps
-
-{{< cards >}}
-{{% card link="/reference/apis/" %}}
-{{% card link="/operate/modules/configure-modules/" %}}
-{{% card link="/operate/install/setup/" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/viam-server/debug-endpoints.md b/docs/operate/reference/viam-server/debug-endpoints.md
deleted file mode 100644
index c1c5271ff2..0000000000
--- a/docs/operate/reference/viam-server/debug-endpoints.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: "Debug Endpoints"
-linkTitle: "Debug Endpoints"
-weight: 130
-type: "docs"
-description: "Advanced debugging endpoints available in viam-server for troubleshooting and development."
-date: "2025-05-19"
----
-
-The RDK (Robot Development Kit) that powers `viam-server` includes several debug endpoints that expose server internals.
-These endpoints can be helpful during development or when troubleshooting complex issues:
-
-- [`pprof`](#pprof)
-- [`graph`](#graph)
-
-## `pprof`
-
-Setting `enable_web_profile` to `true` in your machine configuration allows you to visualize runtime profiling data by opening a locally hosted webpage that displays profiling data.
-The pprof tool provides the following information about machine performance:
-
-- CPU usage
-- Memory allocation
-- Goroutine blocking
-- Execution tracing
-
-For more detailed information on using pprof, refer to the [Go pprof documentation](https://pkg.go.dev/net/http/pprof).
-
-### Configuration
-
-To enable the pprof endpoints, set `enable_web_profile` to `true` in your machine configuration:
-
-1. Navigate to the **CONFIGURE** tab of your machine
-1. Click on the **...** menu next to your machine part in the left-hand menu
-1. Select **Edit JSON**
-1. Add the `enable_web_profile` field at the root level of your configuration:
-
-```json
-{
-  "components": [...],
-  "services": [...],
-  "enable_web_profile": true
-}
-```
-
-{{< alert title="Caution" color="caution" >}}
-The debug endpoints expose internal details about your machine's configuration and runtime behavior.
-Only enable these endpoints in development environments.
-{{< /alert >}}
-
-### Available Endpoints
-
-Once enabled, you can access the pprof interface by navigating to `https://localhost:8080/debug/pprof/` in your browser.
-
-The following pprof routes are available:
-
-- `/debug/pprof/cmdline`: Command line arguments used to start the process
-- `/debug/pprof/profile`: CPU profile data (30-second sample by default)
-- `/debug/pprof/symbol`: Symbol lookup for program counters
-- `/debug/pprof/trace`: Execution trace data
-
-## `graph`
-
-The `/debug/graph` endpoint shows a graphical representation of the machine resources managed by the RDK.
-
-To access this endpoint, visit `https://localhost:8080/debug/graph` on the machine.
-
-### Layout Options
-
-To view different [layouts](https://graphviz.org/docs/layouts/), use the `layout` query parameter:
-
-The following example URL specifies the `circo` layout:
-
-```txt
-https://localhost:8080/debug/graph?layout=circo
-```
-
-Available layout options include:
-
-- `dot` (default): Hierarchical layout
-- `neato`: Spring model layout
-- `fdp`: Force-directed layout
-- `sfdp`: Multiscale version of fdp for large graphs
-- `circo`: Circular layout
-- `twopi`: Radial layout
-- `osage`: Array-based layout
-- `text`: raw [DOT](https://graphviz.org/doc/info/lang.html) text of the graph, for use with external tools
-
-## Next Steps
-
-{{< cards >}}
-{{% card link="/monitor/troubleshoot/" %}}
-{{% card link="/operate/reference/viam-server/manage-viam-server/" %}}
-{{% card link="/monitor/troubleshoot/" %}}
-{{< /cards >}}
diff --git a/docs/operate/reference/viam-server/manage-viam-server.md b/docs/operate/reference/viam-server/manage-viam-server.md
deleted file mode 100644
index 2a3a4397ad..0000000000
--- a/docs/operate/reference/viam-server/manage-viam-server.md
+++ /dev/null
@@ -1,382 +0,0 @@
----
-title: "Manage viam-server"
-linkTitle: "Manage viam-server"
-weight: 120
-no_list: true
-type: docs
-draft: false
-images: ["/installation/thumbnails/manage.png"]
-imageAlt: "Manage viam-server"
-description: "If you have manually installed viam-server, you can chose to run it as a system service or on the command line."
-date: "2024-08-16"
-# updated: ""  # When the content was last entirely checked
-aliases:
-  - /installation/update/
-  - /installation/manage-viam-server/
-  - /get-started/installation/manage-viam-server/
----
-
-If you have manually [installed `viam-server`](/operate/install/setup/), you can chose to run it as a system service or directly on the command line.
-Running as a system service enables you to configure `viam-server` to start automatically when your system boots, and is the [default installation option](/operate/install/setup/#installation-methods-viam-agent-versus-manual) on Linux.
-Running on the command line is suitable for local development.
-
-{{< alert title="Note" color="note" >}}
-If you have installed `viam-agent`, see [Manage `viam-agent`](/manage/reference/viam-agent/manage-viam-agent/) instead.
-{{< /alert >}}
-
-## Run `viam-server`
-
-Select the tab for your platform:
-
-{{< tabs name="Managing viam-server">}}
-{{% tab name="Linux"%}}
-
-### Run as a system service
-
-After [installation](/operate/install/setup/), the `viam-server` [AppImage](https://appimage.org/) binary will be located at <file>/usr/local/bin/viam-server</file>, and a `systemd` service file will be placed at <file>/etc/systemd/system/viam-server.service</file>.
-By default, `viam-server` is configured to start when the machine boots.
-
-Running `viam-server` as a system service is the recommended method for Linux.
-
-You can use the following commands to manage `viam-server` when installed as a system service.
-These commands require that you store your machine cloud credentials file at <file>/etc/viam.json</file>.
-
-#### Start
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl start viam-server
-```
-
-#### Stop
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl stop viam-server
-```
-
-#### Restart
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl restart viam-server
-```
-
-#### Enable (start automatically with system boot, default)
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl enable viam-server
-```
-
-#### Disable (do not start automatically with system boot)
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl disable viam-server
-```
-
-<br>
-
-### Run from the command line
-
-When running `viam-server` on the command line, you can use the following commands to manage the process.
-If `viam-server` is already running as a system service, be sure to stop the service first before using these commands.
-
-#### Start
-
-Run the following on the command line to start `viam-server`, providing the path to your configuration file:
-
-```sh {class="command-line" data-prompt="$"}
-sudo viam-server -config /path/to/my/config.json
-```
-
-If you followed the [Installation Guide](/operate/install/setup/), your machine's cloud credentials file is available at <file>/etc/viam.json</file>.
-You can provide this path in the above command, or move the configuration file to a desired location and change the path in this command accordingly.
-
-Note that on a Raspberry Pi, `viam-server` must always run as `root` (using `sudo`) in order to access the DMA subsystem for GPIO.
-When running `viam-server` from your home directory on a Linux computer, you do not need to use `sudo`.
-
-#### Stop
-
-Press **Ctrl + C** on your keyboard within the terminal session where you are running `viam-server` to stop it.
-
-{{% /tab %}}
-
-{{% tab name="macOS"%}}
-
-### Run from the command line
-
-After [installation](/operate/install/setup/), `viam-server` can be run directly on the command line.
-
-Running `viam-server` on the command line is the recommended method for macOS.
-
-You can use the following commands to manage `viam-server` on the command line:
-
-#### Start
-
-Run the following on the command line to start `viam-server`, providing the path to your own configuration file:
-
-```sh {class="command-line" data-prompt="$"}
-viam-server -config /path/to/my/config.json
-```
-
-If you followed the [Installation Guide](/operate/install/setup/), your machine's configuration file is available in your <file>~/Downloads/</file> directory, named similarly to <file>viam-machinename-main.json</file>.
-You can provide this path in the above command, or move the configuration file to a desired location and change the path in this command accordingly.
-
-#### Stop
-
-Type **Ctrl + C** on your keyboard within the terminal session where you are running `viam-server` to stop it.
-
-<br>
-
-### Run as a system service
-
-The brew installation of `viam-server` CANNOT be run as a system service in the
-background. If you would like to run `viam-server` in the background, install
-[`viam-agent`](/manage/reference/viam-agent/) instead.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Update `viam-server`
-
-The steps to update `viam-server` differ depending on your installation method.
-To determine your installation method, check if the `viam-agent` process is running.
-Run the following command:
-
-```sh {class="command-line" data-prompt="$" data-output="2"}
-ps aux | grep viam-agent
-root      566431  0.5  0.2 1247148 20336 ?       Ssl  11:24   0:00 /opt/viam/bin/viam-agent --config /etc/viam.json
-```
-
-If the output includes a process named `viam-agent`, you used `viam-agent` to install `viam-server`.
-Follow the steps to use `viam-agent` to update `viam-server`.
-
-If the output does not include a process named `viam-agent`, you did not use `viam-agent`.
-Follow the manual steps to update the standalone version.
-
-{{< tabs >}}
-{{% tab name="Installed with viam-agent" %}}
-
-By default, `viam-agent` automatically upgrades to the latest stable version of `viam-server`.
-You can change this behavior in the [`version_control` settings of your machine](/manage/reference/viam-agent/#version-control).
-For example, the following `version_control` configuration will always update to the latest stable release of `viam-agent` and the latest development release of `viam-server`:
-
-```json {class="line-numbers linkable-line-numbers" data-line=""}
-{
-  "agent": {
-    "version_control": {
-      "agent": "stable",
-      "viam-server": "dev"
-    }
-  },
-  "components": [ ... ]
-}
-```
-
-{{% /tab %}}
-{{% tab name="Manual" %}}
-
-To update to the newest RDK version, you need to update your `viam-server`.
-Select the tab for your platform:
-
-{{< tabs name="Updating viam-server" >}}
-{{% tab name=Linux %}}
-
-`viam-server` is distributed for Linux as an [AppImage](https://appimage.org/), and includes a built-in self-update feature.
-When you [run `viam-server`](#run-viam-server) as a service on Linux, it will check for updates automatically on launch, and update itself if a newer version is detected.
-
-The automatic update behavior of `viam-server` should meet the needs of most deployments, but if you need to manually force an update, you can do so with the `--aix-update` flag:
-
-```sh {class="command-line" data-prompt="$"}
-sudo viam-server --aix-update
-```
-
-{{% /tab %}}
-{{% tab name=macOS %}}
-
-`viam-server` is distributed for macOS through the Homebrew package manager, which includes a built-in update feature.
-
-To upgrade to the latest version of `viam-server` using Homebrew:
-
-```sh {class="command-line" data-prompt="$"}
-brew upgrade viam-server
-```
-
-Homebrew does not support automatic updates, so you will need to manually perform this step each time you wish to check for updates.
-We recommend running `brew upgrade viam-server` on a regular basis.
-{{% /tab %}}
-
-{{< /tabs >}}
-{{% /tab %}}
-{{< /tabs >}}
-
-### Disable automatic updates
-
-{{< tabs >}}
-{{% tab name="Installed with viam-agent" %}}
-
-To disable automatic updates, configure the [`version_control` settings of your machine](/manage/reference/viam-agent/#version-control) to a specific version number.
-For example, the following `version_control` configuration pins `viam-server` to version `0.52.1`, preventing `viam-server` from updating to a more recent version:
-
-```json {class="line-numbers linkable-line-numbers" data-line=""}
-{
-  "agent": {
-    "version_control": {
-      "agent": "stable",
-      "viam-server": "0.52.1"
-    }
-  },
-  "components": [ ... ]
-}
-```
-
-If you are changing to a different version of `viam-server` and `viam-agent`, `viam-agent` restarts itself automatically.
-This also restarts `viam-server`.
-{{% /tab %}}
-{{% tab name="Manual" %}}
-
-`viam-server` automatically checks for updates.
-On Linux, you can disable automatic `viam-server` updates.
-To disable the updates, open <file>/etc/systemd/system/viam-server.service</file> and comment out the line that starts with `ExecStartPre`.
-Add a `#` character at the beginning of the line so that it matches the following:
-
-```sh
-# ExecStartPre=-/usr/local/bin/viam-server --aix-update
-```
-
-Then, reload the service file with the following command:
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl daemon-reload
-```
-
-To resume automatic update checking, delete the leading `#` character in <file>/etc/systemd/system/viam-server.service</file>, then run `sudo systemctl daemon-reload` again.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## View `viam-server` logs
-
-`viam-server` writes log messages as it starts up and runs, providing useful information when managing or troubleshooting the process.
-Use the following commands to view these log messages locally on your system.
-
-{{< alert title="Tip" color="tip" >}}
-If your system is able to connect to Viam, you can also view logs in the **LOGS** tab.
-{{< /alert >}}
-
-Select the tab below for your platform:
-
-{{< tabs name="View logs">}}
-{{% tab name="Linux"%}}
-
-### As a system service
-
-If you are running `viam-server` as a system service, run the following command to view log messages:
-
-```sh {class="command-line" data-prompt="$"}
-sudo journalctl --unit=viam-server
-```
-
-Use the arrow keys to page vertically or horizontally through the log messages.
-
-You can also "tail" the logs, viewing new messages as they come in with:
-
-```sh {class="command-line" data-prompt="$"}
-sudo journalctl -f --unit=viam-server
-```
-
-Use the q key to stop following the logs.
-
-You can also view log messages specific to `viam-server` in the `syslog` with the following command:
-
-```sh {class="command-line" data-prompt="$"}
-grep viam-server /var/log/syslog
-```
-
-### From the command line
-
-If you are running `viam-server` on the command line, log messages are written to standard out (`stdout`) in the same terminal session you started `viam-server` in.
-
-You can also view log messages specific to `viam-server` in the `syslog` with the following command:
-
-```sh {class="command-line" data-prompt="$"}
-grep viam-server /var/log/syslog
-```
-
-{{% /tab %}}
-
-{{% tab name="macOS" %}}
-
-When running `viam-server` on macOS, log messages are written to standard out (`stdout`) in the same terminal session you started `viam-server` in.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Uninstall `viam-server`
-
-{{< tabs name="Uninstall viam-server">}}
-{{% tab name="Linux"%}}
-
-Remove the system installed service with the following three commands:
-
-```sh {class="command-line" data-prompt="$"}
-sudo systemctl disable --now viam-server
-sudo rm /etc/systemd/system/viam-server.service
-sudo systemctl daemon-reload
-```
-
-To remove the machine cloud credentials file, run:
-
-```sh {class="command-line" data-prompt="$"}
-sudo rm /etc/viam.json
-```
-
-{{< alert title="Caution" color="caution" >}}
-If you remove the machine cloud credentials file you will not be able to connect to your machine.
-You can only restore this file if you have access to the machine configuration.
-{{< /alert >}}
-
-To remove various Viam caches and logs for the root (service) user, run:
-
-```sh {class="command-line" data-prompt="$"}
-sudo rm -r /root/.viam/
-```
-
-If you ever run `viam-server` directly, to remove various Viam caches and logs for your own user run:
-
-```sh {class="command-line" data-prompt="$"}
-rm -r ~/.viam/
-```
-
-To remove the `viam-server` binary itself, run:
-
-```sh {class="command-line" data-prompt="$"}
-sudo rm /usr/local/bin/viam-server
-```
-
-{{% /tab %}}
-{{% tab name="macOS" %}}
-
-Uninstall `viam-server` with the following command:
-
-```sh {class="command-line" data-prompt="$"}
-brew uninstall viam-server
-```
-
-To remove various Viam caches and logs, run:
-
-```sh {class="command-line" data-prompt="$"}
-rm -r ~/.viam/
-```
-
-To remove the machine cloud credentials file, run:
-
-```sh {class="command-line" data-prompt="$"}
-rm ~/Downloads/viam-<your-part-name>.json
-```
-
-For example, `rm ~/Downloads/viam-mymachine1-main.json`.
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Troubleshooting
-
-You can find additional assistance in the [Troubleshooting section](/manage/troubleshoot/troubleshoot/).
diff --git a/docs/operate/reference/wifi-credentials.md b/docs/operate/reference/wifi-credentials.md
deleted file mode 100644
index 45919d8380..0000000000
--- a/docs/operate/reference/wifi-credentials.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: "Add WiFi Credentials to a Raspberry Pi"
-linkTitle: "Add WiFi Credentials"
-weight: 96
-type: "docs"
-description: "Update or add WiFi network credentials on a Raspberry Pi."
-date: "2022-01-01"
----
-
-If you move your Raspberry Pi to a different WiFi network, you will have to update the WiFi credentials.
-
-You can update the WiFi configuration by creating a new `wpa_supplicant.conf` file on the "boot" partition:
-
-1. Plug your Pi's microSD card into your computer and create a plain text file called `wpa_supplicant.conf`.
-
-2. Paste the following example into the file, replacing "Name of your wireless LAN" and "Password for your wireless LAN" with your credentials.
-   Be sure to use UNIX (LF) line breaks in your text editor.
-
-3. Save the file and eject the microSD card.
-
-4. Put the microSD card back into the Pi and boot the Pi.
-
-The `wpa_supplicant.conf` file will be read by the Pi on boot, and the file will disappear but the WiFi credentials will be updated.
-
-You can duplicate the "network" section to add additional WiFi networks (for example your work, and your home).
-
-The "priority" attribute is optional and can be used to prioritize networks if multiple networks are configured (higher numbers are prioritized).
-
-```bash {class="line-numbers linkable-line-numbers"}
-ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
-update_config=1
-country=us
-
-network={
- ssid="Name of your wireless LAN"
- psk="Password for your wireless LAN"
- priority=10
-}
-
-network={
-ssid="Name of your other wireless LAN"
-psk="Password for your other wireless LAN"
-priority=20
-}
-```
diff --git a/docs/organization/access.md b/docs/organization/access.md
index 8d89e1a11d..7c664fb08a 100644
--- a/docs/organization/access.md
+++ b/docs/organization/access.md
@@ -7,6 +7,7 @@ type: "docs"
 no_list: true
 description: "To collaborate with others on your machines, you can grant users permissions for individual machines or entire locations."
 aliases:
+  - /operate/control/api-keys/
   - /cloud/rbac/
   - /fleet/rbac/
   - /manage/manage/access/
diff --git a/docs/reference/_index.md b/docs/reference/_index.md
index 134559ff19..e9272fc11d 100644
--- a/docs/reference/_index.md
+++ b/docs/reference/_index.md
@@ -10,6 +10,8 @@ open_on_desktop: true
 manualLink: "/reference/overview/"
 description: "Technical reference documentation for the Viam platform: APIs, SDKs, components, services, and more."
 aliases:
+  - /operate/reference/
+  - /operate/reference/controls-package/
   - /reference/architecture/
   - /reference/architecture/parts/
   - /reference/architecture/machine-to-machine-comms/
diff --git a/docs/reference/apis/components/_index.md b/docs/reference/apis/components/_index.md
index af19356c06..46581e6d8f 100644
--- a/docs/reference/apis/components/_index.md
+++ b/docs/reference/apis/components/_index.md
@@ -7,6 +7,7 @@ layout: "empty"
 canonical: "/reference/apis/"
 type: "docs"
 aliases:
+  - /operate/modules/component-apis/
   - /dev/reference/apis/components/
   - /appendix/apis/components/
   - /components/
diff --git a/docs/reference/apis/components/arm.md b/docs/reference/apis/components/arm.md
index ef6f8ab46e..2135a48354 100644
--- a/docs/reference/apis/components/arm.md
+++ b/docs/reference/apis/components/arm.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/arm.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/arm/
   - /dev/reference/apis/components/arm/
   - /appendix/apis/components/arm/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/base.md b/docs/reference/apis/components/base.md
index 16bf421ebc..8ad118601b 100644
--- a/docs/reference/apis/components/base.md
+++ b/docs/reference/apis/components/base.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/base.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/base/
   - /dev/reference/apis/components/base/
   - /appendix/apis/components/base/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/board.md b/docs/reference/apis/components/board.md
index a7017ac611..b86daea7be 100644
--- a/docs/reference/apis/components/board.md
+++ b/docs/reference/apis/components/board.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/board.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/board/
   - /dev/reference/apis/components/board/
   - /appendix/apis/components/board/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/button.md b/docs/reference/apis/components/button.md
index 1325587096..4c44b3c4f2 100644
--- a/docs/reference/apis/components/button.md
+++ b/docs/reference/apis/components/button.md
@@ -9,6 +9,7 @@ images: ["/icons/components/button.svg"]
 date: "2025-02-20"
 # updated: ""  # When the content was last entirely checked
 aliases:
+  - /operate/modules/component-apis/button/
   - /dev/reference/apis/components/button/
 ---
 
diff --git a/docs/reference/apis/components/camera.md b/docs/reference/apis/components/camera.md
index 09e2996ae1..2d41a58df2 100644
--- a/docs/reference/apis/components/camera.md
+++ b/docs/reference/apis/components/camera.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/camera.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/camera/
   - /dev/reference/apis/components/camera/
   - /appendix/apis/components/camera/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/encoder.md b/docs/reference/apis/components/encoder.md
index 6e7c851c9f..a669de6d0b 100644
--- a/docs/reference/apis/components/encoder.md
+++ b/docs/reference/apis/components/encoder.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/encoder.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/encoder/
   - /dev/reference/apis/components/encoder/
   - /appendix/apis/components/encoder/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/gantry.md b/docs/reference/apis/components/gantry.md
index c541bfa63a..e47c080869 100644
--- a/docs/reference/apis/components/gantry.md
+++ b/docs/reference/apis/components/gantry.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/gantry.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/gantry/
   - /dev/reference/apis/components/gantry/
   - /appendix/apis/components/gantry/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/generic.md b/docs/reference/apis/components/generic.md
index fb3075b0ca..b3556f5b69 100644
--- a/docs/reference/apis/components/generic.md
+++ b/docs/reference/apis/components/generic.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/generic.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/generic/
   - /appendix/apis/components/generic/
 # updated: ""  # When the content was last entirely checked
 ---
diff --git a/docs/reference/apis/components/gripper.md b/docs/reference/apis/components/gripper.md
index 870bb15461..c925cbc7a1 100644
--- a/docs/reference/apis/components/gripper.md
+++ b/docs/reference/apis/components/gripper.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/gripper.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/gripper/
   - /dev/reference/apis/components/gripper/
   - /appendix/apis/components/gripper/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/input-controller.md b/docs/reference/apis/components/input-controller.md
index 1473b0e084..f1b73c0e3b 100644
--- a/docs/reference/apis/components/input-controller.md
+++ b/docs/reference/apis/components/input-controller.md
@@ -9,6 +9,7 @@ icon: true
 images: ["/icons/components/controller.svg"]
 date: "2022-01-01"
 aliases:
+  - /operate/modules/component-apis/input-controller/
   - /appendix/apis/components/input-controller/
 # updated: ""  # When the content was last entirely checked
 ---
diff --git a/docs/reference/apis/components/motor.md b/docs/reference/apis/components/motor.md
index e9e6c43d44..9c5ee78d7d 100644
--- a/docs/reference/apis/components/motor.md
+++ b/docs/reference/apis/components/motor.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/motor.svg"]
 date: "2024-10-10"
 aliases:
+  - /operate/modules/component-apis/motor/
   - /dev/reference/apis/components/motor/
   - /appendix/apis/components/motor/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/movement-sensor.md b/docs/reference/apis/components/movement-sensor.md
index 484d39e86c..affb354b56 100644
--- a/docs/reference/apis/components/movement-sensor.md
+++ b/docs/reference/apis/components/movement-sensor.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/imu.svg"]
 date: "2022-10-10"
 aliases:
+  - /operate/modules/component-apis/movement-sensor/
   - /dev/reference/apis/components/movement-sensor/
   - /appendix/apis/components/movement-sensor/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/power-sensor.md b/docs/reference/apis/components/power-sensor.md
index cf949e589d..67da6090e9 100644
--- a/docs/reference/apis/components/power-sensor.md
+++ b/docs/reference/apis/components/power-sensor.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/power-sensor.svg"]
 date: "2022-10-10"
 aliases:
+  - /operate/modules/component-apis/power-sensor/
   - /dev/reference/apis/components/power-sensor/
   - /appendix/apis/components/power-sensor/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/sensor.md b/docs/reference/apis/components/sensor.md
index 0bf1d2a544..345e45c933 100644
--- a/docs/reference/apis/components/sensor.md
+++ b/docs/reference/apis/components/sensor.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/sensor.svg"]
 date: "2022-10-10"
 aliases:
+  - /operate/modules/component-apis/sensor/
   - /dev/reference/apis/components/sensor/
   - /appendix/apis/components/sensor/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/servo.md b/docs/reference/apis/components/servo.md
index bb03849b94..58584b85f0 100644
--- a/docs/reference/apis/components/servo.md
+++ b/docs/reference/apis/components/servo.md
@@ -8,6 +8,7 @@ icon: true
 images: ["/icons/components/servo.svg"]
 date: "2022-10-10"
 aliases:
+  - /operate/modules/component-apis/servo/
   - /dev/reference/apis/components/servo/
   - /appendix/apis/components/servo/
 # updated: ""  # When the content was last entirely checked
diff --git a/docs/reference/apis/components/switch.md b/docs/reference/apis/components/switch.md
index c67644cfc3..ea242cae77 100644
--- a/docs/reference/apis/components/switch.md
+++ b/docs/reference/apis/components/switch.md
@@ -9,6 +9,7 @@ images: ["/icons/components/switch.svg"]
 date: "2025-02-20"
 # updated: ""  # When the content was last entirely checked
 aliases:
+  - /operate/modules/component-apis/switch/
   - /dev/reference/apis/components/switch/
 ---
 
diff --git a/docs/reference/components/_index.md b/docs/reference/components/_index.md
index cdc5fd77b1..c41a9b6de8 100644
--- a/docs/reference/components/_index.md
+++ b/docs/reference/components/_index.md
@@ -8,4 +8,6 @@ canonical: "/reference/components/arm/"
 no_component: true
 empty_node: true
 toc_hide: false
+aliases:
+  - /operate/reference/components/
 ---
diff --git a/docs/reference/components/base/micro-rdk/two_wheeled_base.md b/docs/reference/components/base/micro-rdk/two_wheeled_base.md
index 8d20f4f3b2..335cc6b1bb 100644
--- a/docs/reference/components/base/micro-rdk/two_wheeled_base.md
+++ b/docs/reference/components/base/micro-rdk/two_wheeled_base.md
@@ -7,6 +7,7 @@ description: "Reference for the two_wheeled_base base model. And wire a two-whee
 images: ["/icons/components/base.svg"]
 tags: ["base", "components"]
 aliases:
+  - /operate/reference/components/base/two_wheeled_base/
   - /micro-rdk/base/esp32_wheeled_base/
   - /build/micro-rdk/base/esp32_wheeled_base/
   - /build/micro-rdk/base/two_wheeled_base/
diff --git a/docs/reference/components/board/micro-rdk/esp32.md b/docs/reference/components/board/micro-rdk/esp32.md
index 2e17161451..37527d3b61 100644
--- a/docs/reference/components/board/micro-rdk/esp32.md
+++ b/docs/reference/components/board/micro-rdk/esp32.md
@@ -8,6 +8,7 @@ images: ["/installation/thumbnails/esp32-espressif.png"]
 imageAlt: "E S P 32 - espressif"
 tags: ["board", "components"]
 aliases:
+  - /operate/reference/components/board/esp32/
   - /micro-rdk/board/esp32/
   - /build/micro-rdk/board/esp32/
   - /components/board/esp32/
diff --git a/docs/reference/components/camera/micro-rdk/esp32-camera.md b/docs/reference/components/camera/micro-rdk/esp32-camera.md
index 5b06fb9622..3744f96d20 100644
--- a/docs/reference/components/camera/micro-rdk/esp32-camera.md
+++ b/docs/reference/components/camera/micro-rdk/esp32-camera.md
@@ -10,6 +10,7 @@ component_description: "An `OV2640` or `OV3660` camera connected to an esp32 boa
 micrordk_component: true
 date: "2024-08-28"
 aliases:
+  - /operate/reference/components/camera/esp32-camera/
   - /components/camera/esp32-camera/
   - "/reference/components/camera/esp32-camera-micro-rdk/"
   - "/operate/reference/components/camera/esp32-camera-micro-rdk/"
diff --git a/docs/reference/components/camera/micro-rdk/fake.md b/docs/reference/components/camera/micro-rdk/fake.md
index e6666bbc31..7f96c4ee5c 100644
--- a/docs/reference/components/camera/micro-rdk/fake.md
+++ b/docs/reference/components/camera/micro-rdk/fake.md
@@ -7,6 +7,7 @@ description: "Reference for the fake camera model on Micro-RDK. Returns a static
 images: ["/icons/components/camera.svg"]
 tags: ["camera", "components"]
 aliases:
+  - /operate/reference/components/camera/fake-micro-server/
   - /components/camera/fake-micro-server/
   - "/reference/components/camera/fake-micro-rdk/"
   - "/operate/reference/components/camera/fake-micro-rdk/"
diff --git a/docs/reference/device-setup/_index.md b/docs/reference/device-setup/_index.md
index 3a761f9357..0cd0b0e9d8 100644
--- a/docs/reference/device-setup/_index.md
+++ b/docs/reference/device-setup/_index.md
@@ -5,6 +5,8 @@ weight: 55
 layout: "docs"
 type: "docs"
 description: "Board-specific setup instructions for single-board computers and microcontrollers supported by Viam."
+aliases:
+  - /operate/reference/prepare/
 ---
 
 Before installing Viam on a single-board computer, follow the setup guide for your board to ensure the OS and firmware are ready.
diff --git a/docs/reference/device-setup/rpi-setup.md b/docs/reference/device-setup/rpi-setup.md
index a86a404b0d..34eab51d7c 100644
--- a/docs/reference/device-setup/rpi-setup.md
+++ b/docs/reference/device-setup/rpi-setup.md
@@ -8,6 +8,7 @@ images: ["/installation/thumbnails/raspberry-pi-4-b-2gb.png"]
 imageAlt: "Raspberry Pi"
 no_list: true
 aliases:
+  - /operate/reference/wifi-credentials/
   - /operate/reference/prepare/rpi-setup/
   - /getting-started/rpi-setup/
   - /installation/rpi-setup/
diff --git a/docs/reference/device-setup/setup-micro/_index.md b/docs/reference/device-setup/setup-micro/_index.md
index 013e97502c..c9ac4b5f97 100644
--- a/docs/reference/device-setup/setup-micro/_index.md
+++ b/docs/reference/device-setup/setup-micro/_index.md
@@ -9,6 +9,7 @@ imageAlt: "Install Viam"
 no_list: false
 description: "Install the lightweight version of the software that drives hardware and connects your device to the cloud."
 aliases:
+  - /operate/reference/viam-micro-server/
   - /operate/install/setup-micro/
   - /installation/microcontrollers/
   - /installation/prepare/microcontrollers/
diff --git a/docs/reference/device-setup/setup-micro/micro-module.md b/docs/reference/device-setup/setup-micro/micro-module.md
index 2489b5b537..51d41529f7 100644
--- a/docs/reference/device-setup/setup-micro/micro-module.md
+++ b/docs/reference/device-setup/setup-micro/micro-module.md
@@ -11,6 +11,7 @@ languages: ["rust"]
 date: "2024-12-11"
 # updated: ""  # When the content was last entirely checked
 aliases:
+  - /operate/modules/advanced/micro-module/
   - /installation/prepare/microcontrollers/development-setup/
   - /get-started/installation/prepare/microcontrollers/development-setup/
   - /get-started/installation/microcontrollers/development-setup/
diff --git a/docs/reference/device-setup/setup-micro/micro-troubleshooting.md b/docs/reference/device-setup/setup-micro/micro-troubleshooting.md
index 746dbae4fe..159a508ed1 100644
--- a/docs/reference/device-setup/setup-micro/micro-troubleshooting.md
+++ b/docs/reference/device-setup/setup-micro/micro-troubleshooting.md
@@ -7,6 +7,7 @@ images: ["/installation/thumbnails/install.png"]
 imageAlt: "Install viam-micro-server"
 description: "Troubleshooting tips and best practices for installing and using viam-micro-server or other Micro-RDK-based firmware on a microcontroller."
 aliases:
+  - /operate/install/setup-micro/micro-troubleshooting/
   - /operate/reference/viam-micro-server/viam-micro-server-setup/
   - /operate/reference/viam-micro-server/micro-troubleshooting/
   - /operate/get-started/setup-micro/micro-troubleshooting/
diff --git a/docs/reference/glossary/index.md b/docs/reference/glossary/index.md
index 5d7219d8de..c4adf9cf68 100644
--- a/docs/reference/glossary/index.md
+++ b/docs/reference/glossary/index.md
@@ -10,6 +10,7 @@ card:
   weight: 10
   title: Glossary
 aliases:
+  - /operate/reference/glossary/
   - /dev/reference/glossary/
   - "/appendix/glossary/"
 ---
diff --git a/docs/reference/glossary/vision-service.md b/docs/reference/glossary/vision-service.md
index 5d29162aec..960b0b9725 100644
--- a/docs/reference/glossary/vision-service.md
+++ b/docs/reference/glossary/vision-service.md
@@ -1,7 +1,7 @@
 ---
 title: Vision service
 id: vision-service
-full_link: /operate/reference/services/vision/
+full_link: /reference/services/vision/
 short_description: A service that enables machines to interpret visual data from cameras using computer vision and machine learning.
 aka:
 type: "page"
diff --git a/docs/reference/sdks/_index.md b/docs/reference/sdks/_index.md
index 8fea1453f9..29b3eec6d8 100644
--- a/docs/reference/sdks/_index.md
+++ b/docs/reference/sdks/_index.md
@@ -5,6 +5,7 @@ weight: 10
 type: "docs"
 description: "Write code to control your machine with Viam's Python, Go, TypeScript, Flutter, and C++ SDKs."
 aliases:
+  - /operate/control/sdks/
   - /sdks/
 ---
 
diff --git a/docs/reference/services/_index.md b/docs/reference/services/_index.md
index 106827e701..d2d151365f 100644
--- a/docs/reference/services/_index.md
+++ b/docs/reference/services/_index.md
@@ -7,6 +7,8 @@ layout: "docs"
 no_list: true
 description: "Configuration reference for Viam built-in services: per-service models, attributes, and JSON templates."
 date: "2026-04-14"
+aliases:
+  - /operate/reference/services/
 ---
 
 Configuration reference for Viam built-in services. Each page covers available models, configuration attributes, and JSON templates. For API method reference, see [Service APIs](/reference/apis/services/).
diff --git a/docs/reference/services/motion/_index.md b/docs/reference/services/motion/_index.md
index 02866acf23..87c994aba1 100644
--- a/docs/reference/services/motion/_index.md
+++ b/docs/reference/services/motion/_index.md
@@ -119,27 +119,30 @@ For example:
 {{% /tab %}}
 {{% tab name="Go" %}}
 
-The following example assumes your module uses `AlwaysRebuild` and does not have a `Reconfigure` function defined.
-
 ```go {class="line-numbers linkable-line-numbers"}
-// Return the motion service as a dependency
+// Return the built-in motion service as a required dependency.
 func (cfg *Config) Validate(path string) ([]string, []string, error) {
   deps := []string{motion.Named("builtin").String()}
   return deps, nil, nil
 }
 
-// Then use the motion service, for example:
-func (c *Component) MoveAroundInSomeWay() error {
-  c.Motion, err = motion.FromDependencies(deps, "builtin")
+// Store the motion service on the component when the module reconfigures.
+func (c *Component) Reconfigure(ctx context.Context, deps resource.Dependencies, conf resource.Config) error {
+  motionService, err := motion.FromProvider(deps, "builtin")
   if err != nil {
-    return nil, err
+    return err
   }
-  moved, err := c.Motion.Move(context.Background(), motion.MoveReq{
+  c.motion = motionService
+  return nil
+}
+
+// Use the stored motion service, for example:
+func (c *Component) MoveAroundInSomeWay(ctx context.Context) (bool, error) {
+  return c.motion.Move(ctx, motion.MoveReq{
     ComponentName: gripperName,
-    Destination: destination,
-    WorldState: worldState
+    Destination:   destination,
+    WorldState:    worldState,
   })
-  return moved, err
 }
 ```
 
@@ -162,12 +165,10 @@ The [motion service API](/reference/apis/services/motion/) supports the followin
 
 You can test motion on your machine from the [**CONTROL** tab](/monitor/).
 
-![Motion card on the Control tab](/services/motion/motion-rc-card.png)
-
-Enter x and y coordinates to move your machine to, then click the **Move** button to issue a `MoveOnMap()` request.
+Enter X and Y coordinates for your destination in meters, then click **Execute** to issue a `MoveOnMap()` request.
 
 {{< alert title="Info" color="info" >}}
 
-The `plan_deviation_m` for `MoveOnMap()` on calls issued from the **CONTROL** tab is 0.5 m.
+If you leave the **Plan deviation (m)** field blank, `MoveOnMap()` uses the motion service default of 1.0 m.
 
 {{< /alert >}}
diff --git a/docs/try/_index.md b/docs/try/_index.md
index 940990d998..2648182fb9 100644
--- a/docs/try/_index.md
+++ b/docs/try/_index.md
@@ -9,6 +9,8 @@ description: "Hands-on guided tutorials to experience Viam end-to-end."
 manualLink: "/try/overview/"
 date: "2025-01-30"
 aliases:
+  - /operate/hello-world/
+  - /operate/hello-world/first-project/
   - /dev/reference/try-viam/
   - /dev/reference/try-viam/reserve-a-rover/
   - /dev/reference/try-viam/try-viam-tutorial/
diff --git a/docs/try/gazebo-setup.md b/docs/try/gazebo-setup.md
index 2856425cfd..5959fe14b3 100644
--- a/docs/try/gazebo-setup.md
+++ b/docs/try/gazebo-setup.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Set up the Gazebo simulation environment for the inspection tutorial."
 date: "2025-01-30"
 aliases:
+  - /operate/hello-world/first-project/sim-setup/
   - /try/first-project/gazebo-setup/
 ---
 
diff --git a/docs/try/part-1.md b/docs/try/part-1.md
index 142e83b397..043221bf63 100644
--- a/docs/try/part-1.md
+++ b/docs/try/part-1.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Set up a camera, ML model, and vision service to detect defects."
 date: "2025-01-30"
 aliases:
+  - /operate/hello-world/first-project/part-1/
   - /try/first-project/part-1/
 ---
 
@@ -102,7 +103,7 @@ Verify the camera is working. Every component in Viam has a built-in test card r
 
 1. You should still be on the **CONFIGURE** tab with your `inspection-cam` selected
 2. Look for the **Test** section at the bottom of the camera's configuration panel
-3. Click **Test** to expand the camera's test card
+3. Expand the **TEST** section to open the camera's test card
 
 The camera component test card uses the camera API to add an image feed to the Viam app, enabling you to determine whether your camera is working. You should see a live video feed from the simulated camera. This is an overhead view of the conveyor/staging area.
 
diff --git a/docs/try/part-2.md b/docs/try/part-2.md
index cd0656b9e3..883cabef1e 100644
--- a/docs/try/part-2.md
+++ b/docs/try/part-2.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Configure automatic image capture and cloud sync for your inspection system."
 date: "2025-01-30"
 aliases:
+  - /operate/hello-world/first-project/part-2/
   - /try/first-project/part-2/
 ---
 
diff --git a/docs/try/part-3.md b/docs/try/part-3.md
index aa94dc4aab..c31b86b12b 100644
--- a/docs/try/part-3.md
+++ b/docs/try/part-3.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Write inspection logic that detects defective cans."
 date: "2025-01-30"
 aliases:
+  - /operate/hello-world/first-project/part-3/
   - /try/first-project/part-3/
 ---
 
diff --git a/docs/try/part-4.md b/docs/try/part-4.md
index 27d00dae01..c829fd0ce5 100644
--- a/docs/try/part-4.md
+++ b/docs/try/part-4.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Deploy your inspector module and configure queryable detection data capture."
 date: "2025-01-30"
 aliases:
+  - /operate/hello-world/first-project/part-4/
   - /try/first-project/part-4/
 ---
 
@@ -211,7 +212,7 @@ viam module upload --version 0.0.1 --platform linux/arm64 --upload module.tar.gz
 
 1. In the Viam app, go to your machine's **Configure** tab
 2. Click **+** next to your machine part
-3. Select **Component or service**
+3. Select **Configuration block**
 4. Search for your model (for example, `your-namespace:inspection-module:inspector`)
 5. Name it `inspector-service`
 6. Click **Create**
diff --git a/docs/try/part-5.md b/docs/try/part-5.md
index 69e953ee60..535c7ed713 100644
--- a/docs/try/part-5.md
+++ b/docs/try/part-5.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Build a monitoring dashboard for your inspection system using Viam's Teleop interface."
 date: "2025-01-30"
 aliases:
+  - /operate/hello-world/first-project/part-5/
   - /operate/hello-world/first-project/part-6/
   - /try/first-project/part-5/
 ---
diff --git a/docs/what-is-viam/_index.md b/docs/what-is-viam/_index.md
index ed97a1eb06..97b7c049a0 100644
--- a/docs/what-is-viam/_index.md
+++ b/docs/what-is-viam/_index.md
@@ -9,6 +9,7 @@ images: ["/general/understand.png"]
 imageAlt: "Viam platform overview"
 description: "Viam is a software platform for building, deploying, and managing robotics applications."
 aliases:
+  - /operate/reference/architecture/
   - /understand/
   - /understand/what-is-viam/
   - /what-is-viam/problems-viam-solves/
diff --git a/layouts/404.html b/layouts/404.html
index 1d2db6e3e5..ca5373e26a 100644
--- a/layouts/404.html
+++ b/layouts/404.html
@@ -9,8 +9,8 @@ <h2>But maybe these could be helpful?</h2>
         <div class="row-no-margin">
             {{ partial "card.html" (dict "link" "/" "class" "" "customTitle" "" "customDescription" "Get an overview of the Viam platform and how you can configure, program, operate, manage, and collect data from your machines." "customCanonicalLink" "" ) }}
             {{ partial "card.html" (dict "link" "/tutorials/control/drive-rover/" "class" "" "customTitle" "" "customDescription" "" "customCanonicalLink" "" ) }}
-            {{ partial "card.html" (dict "link" "/operate/install/setup/" "class" "" "customTitle" "" "customDescription" "" "customCanonicalLink" "" ) }}
-            {{ partial "card.html" (dict "link" "/operate/" "class" "" "customTitle" "" "customDescription" "" "customCanonicalLink" "" ) }}
+            {{ partial "card.html" (dict "link" "/set-up-a-machine/overview/" "class" "" "customTitle" "" "customDescription" "" "customCanonicalLink" "" ) }}
+            {{ partial "card.html" (dict "link" "/reference/" "class" "" "customTitle" "" "customDescription" "" "customCanonicalLink" "" ) }}
             {{ partial "card.html" (dict "link" "/reference/sdks/" "class" "" "customTitle" "" "customDescription" "" "customCanonicalLink" "" ) }}
         </div>
     </div>
diff --git a/static/include/components/camera-model-next-steps.md b/static/include/components/camera-model-next-steps.md
index 36397ed5ab..f987427982 100644
--- a/static/include/components/camera-model-next-steps.md
+++ b/static/include/components/camera-model-next-steps.md
@@ -1,5 +1,5 @@
 {{< cards >}}
-{{% card link="/operate/reference/components/camera/calibrate/" %}}
-{{% card link="/operate/reference/components/camera/transform/" %}}
+{{% card link="/hardware/common-components/add-a-camera/" %}}
+{{% card link="/reference/components/camera/transform/" %}}
 {{% card link="/services/vision" %}}
 {{< /cards >}}

From e1f28786d261bdb783f99958d37d0f7ad7731487 Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 12:07:16 -0400
Subject: [PATCH 2/8] Complete revisit items: controls-package,
 camera-calibration, rpi wifi, advanced-patterns

- Migrate controls-package as reference/controls-package.md, updated to
  current RDK source (PIDSets attribute, TunedVals field, added Derivative
  and Filter block sections, fixed function name typo)
- Add camera calibration section to add-a-camera page, move calibrate alias
  to camera-calibration.md
- Merge wifi-credentials content into rpi-setup, remove YouTube embed
- Create build-modules/advanced-patterns.md combining content from 4 old
  operate/reference/advanced-modules pages
- Add module-configuration anchor to module-reference.md
- Fix motion service links and minor cleanups across multiple pages

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 docs/build-modules/advanced-patterns.md       | 172 +++++
 docs/build-modules/deploy-a-module.md         |   1 -
 docs/build-modules/module-reference.md        |   8 +
 docs/build-modules/overview.md                |   2 -
 .../common-components/add-a-camera.md         |   5 +-
 docs/hardware/configure-hardware.md           |   2 +-
 docs/hardware/multi-machine/overview.md       |   1 -
 .../frame-system/camera-calibration.md        |   1 +
 docs/reference/controls-package.md            | 686 ++++++++++++++++++
 docs/reference/device-setup/rpi-setup.md      |  33 +-
 docs/reference/services/motion/_index.md      |   4 +-
 .../include/services/apis/generated/motion.md |   8 +-
 12 files changed, 909 insertions(+), 14 deletions(-)
 create mode 100644 docs/build-modules/advanced-patterns.md
 create mode 100644 docs/reference/controls-package.md

diff --git a/docs/build-modules/advanced-patterns.md b/docs/build-modules/advanced-patterns.md
new file mode 100644
index 0000000000..f4a822f0b8
--- /dev/null
+++ b/docs/build-modules/advanced-patterns.md
@@ -0,0 +1,172 @@
+---
+linkTitle: "Advanced patterns"
+title: "Advanced module patterns"
+weight: 38
+layout: "docs"
+type: "docs"
+description: "Define new resource APIs, deploy custom components as remote parts, and package modules with Docker."
+date: "2026-04-20"
+aliases:
+  - /operate/reference/advanced-modules/
+  - /operate/reference/advanced-modules/create-subtype/
+  - /operate/reference/advanced-modules/custom-components-remotes/
+  - /operate/reference/advanced-modules/docker-modules/
+  - /program/extend/
+  - /modular-resources/advanced/
+  - /registry/advanced/
+  - /extend/modular-resources/create/create-subtype/
+  - /modular-resources/advanced/create-subtype/
+  - /registry/advanced/create-subtype/
+  - /program/extend/sdk-as-server/
+  - /program/extend/custom-components-remotes/
+  - /extend/custom-components-remotes/
+  - /modular-resources/advanced/custom-components-remotes/
+  - /registry/advanced/custom-components-remotes/
+---
+
+Some use cases require approaches beyond the standard module workflow. This page covers three advanced patterns: defining a new resource API, deploying custom components as remote parts, and packaging modules with Docker.
+
+## Define a new resource API
+
+You can define a new, custom resource API if:
+
+- You have a resource that does not fit into any of the existing [component](/reference/apis/#component-apis) or [service](/reference/apis/#service-apis) APIs.
+- You have a resource that could fit into an existing API, but you want different methods and messages.
+
+{{% alert title="Tip" color="tip" %}}
+
+Defining a new resource API is significantly more complex than using an existing API. In most cases, use an existing API instead.
+
+If you want to use most of an existing API but need a few additional functions, use the `DoCommand` endpoint with [extra parameters](/reference/sdks/use-extra-params/) to add custom functionality.
+
+If your use case uses only `DoCommand` and no other API methods, define a new model of [generic component](/reference/components/generic/) or [generic service](/reference/services/generic/).
+
+{{% /alert %}}
+
+### Steps to define a new API
+
+Viam uses [protocol buffers](https://protobuf.dev/) for API definition. To define a new API:
+
+1. Decide whether your custom API is a component (interfaces with hardware) or a service (provides higher-level functionality).
+
+2. Choose a name for your API (called the subtype). Determine a valid API namespace triplet. For example, `your-org-namespace:component:gizmo`.
+
+3. Create a directory for your module with a `src` subdirectory.
+
+   {{% alert title="Tip" color="tip" %}}
+   If you are writing your module in Python, you can use this [module generator tool](https://github.com/viam-labs/generator-viam-module) to generate stub files for the new API and a module that implements it.
+   {{% /alert %}}
+
+4. Write the proto methods in a `<API name>.proto` file inside `src/proto/`. For reference:
+   - [Example modular component proto file](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/proto/gizmo.proto)
+   - [Example modular service proto file](https://github.com/viam-labs/speech-service-api/blob/main/src/proto/speech.proto)
+   - [Built-in Viam resource proto files](https://github.com/viamrobotics/api/tree/main/proto/viam)
+
+5. Define the proto methods in Python or Go in a file called `api.py` or `api.go`:
+   - [Example component in Python](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/gizmo/api.py)
+   - [Example service in Python](https://github.com/viam-labs/speech-service-api/blob/main/src/speech_service_api/api.py)
+
+6. Generate the required configuration files (`buf.yaml`, `buf.gen.yaml`, `buf.lock`). See the [Buf documentation](https://buf.build/docs/generate/usage/).
+
+7. Use the protobuf compiler to [generate](https://buf.build/docs/tutorials/getting-started-with-buf-cli/#generate-code) all other necessary protocol buffer code from your `.proto` file.
+
+### After defining your API
+
+Once your API is defined, [create a model that implements it](/build-modules/write-a-driver-module/).
+
+Keep in mind:
+- You cannot use [SDKs](/reference/sdks/) to call your new API unless you build out the client to support it. Write code against the API in the language you used to define it.
+- You need a local copy of the module code on whatever machine runs client code against it.
+- Import the API definition from the module directory. For example, in Python: `from path.to.module.src.gizmo import Gizmo`.
+
+## Custom components as remote parts
+
+Running modular resources on the computer directly connected to your components is the preferred approach. However, if you cannot use modular resources because you need to host `viam-server` on a non-Linux system or have a compilation issue, you can code a custom resource implementation, host it on a server, and add it as a [remote part](/hardware/multi-machine/add-a-remote-part/) of your machine.
+
+Once configured, you control the custom component with the Viam SDKs like any other component.
+
+### Steps
+
+{{< tabs >}}
+{{% tab name="Go" %}}
+
+1. Code a new model of a built-in resource type by creating a new interface that implements the required methods from its [API definition](/reference/apis/).
+2. Register the custom component on a new gRPC server instance and start the server.
+3. Add the server as a [remote part](/hardware/multi-machine/add-a-remote-part/) of your machine.
+4. (Optional) Ensure the remote server automatically starts when the machine boots.
+
+Each remote server can host one or many custom components.
+
+{{% /tab %}}
+{{% tab name="Python" %}}
+
+{{< alert title="Tip" color="tip" >}}
+For detailed instructions, see the full example in the [Python SDK documentation](https://python.viam.dev/examples/example.html#subclass-a-component).
+{{< /alert >}}
+
+1. Code a new model of a built-in resource type by subclassing it (for example, `sensor` or `arm`). Implement any required methods from its [API definition](/reference/apis/).
+2. Register the custom component on a new gRPC server instance using the [`viam.rpc` library](https://python.viam.dev/autoapi/viam/rpc/index.html).
+3. Add the server as a [remote part](/hardware/multi-machine/add-a-remote-part/) of your machine.
+4. (Optional) Ensure the remote server automatically starts when the machine boots.
+
+Each remote server can host one or many custom components.
+
+{{% /tab %}}
+{{< /tabs >}}
+
+{{% alert title="Important" color="note" %}}
+
+You must define all methods belonging to a built-in resource type when defining a new model. Otherwise, the class will not instantiate.
+
+- In Python, raise `NotImplementedError()` or use `pass` in methods you do not want to implement.
+- In Go, return `errUnimplemented`.
+
+{{% /alert %}}
+
+## Deploy a module using Docker
+
+In rare cases, you may need to package and deploy a module using Docker. Use cases include:
+
+- Your module has complex system dependencies that cannot be easily installed on a machine.
+- You use a large container image and some layers are already cached on the machine.
+- You have specific security requirements.
+
+If you deploy using Docker, create a "first run" script to handle setup. This is not recommended for modules that do not use Docker.
+
+### Use a `first_run` script
+
+1. Create a tarball containing:
+
+   - The module's entrypoint script or binary:
+
+     ```sh {class="command-line" data-prompt="$"}
+     #!/bin/bash
+     exec docker run <YOUR_CONTAINER_IMAGE> <YOUR_CONTAINER_OPTIONS>
+     ```
+
+   - A [meta.json](/build-modules/module-reference/#metajson-schema) file.
+
+   - A first-run script that runs during setup:
+
+     ```sh {class="command-line" data-prompt="$"}
+     #!/usr/bin/env bash
+     docker pull mongo:6
+     echo "Setup complete."
+     exit 0
+     ```
+
+   [This example Makefile](https://github.com/viam-labs/wifi-sensor/blob/7823b6ad3edcbbbf20b06c34b3181453f5f3f078/Makefile) builds a module binary and bundles it with a meta.json and first-run script.
+
+2. Edit meta.json to include the `first_run` field:
+
+   ```json
+   {
+     "first_run": "first_run.sh"
+   }
+   ```
+
+3. Configure the module on your machine normally. The first-run script executes once when `viam-server` receives a new configuration, and once per version update.
+
+4. (Optional) To force the first-run script to run again without changing the module version, delete the marker file at `.viam/packages/data/module/<id>/bin.first_run_succeeded`.
+
+5. (Optional) The default first-run timeout is 1 hour. Adjust with `"first_run_timeout": "5m"` in the module configuration.
diff --git a/docs/build-modules/deploy-a-module.md b/docs/build-modules/deploy-a-module.md
index c4f73ef51c..31b8503020 100644
--- a/docs/build-modules/deploy-a-module.md
+++ b/docs/build-modules/deploy-a-module.md
@@ -8,7 +8,6 @@ description: "Package, upload, and distribute a module through the Viam registry
 date: "2025-01-30"
 aliases:
   - /operate/modules/deploy-a-module/
-  - /operate/reference/advanced-modules/docker-modules/
   - /build/development/deploy-a-module/
   - /development/deploy-a-module/
   - /extend/modular-resources/upload/
diff --git a/docs/build-modules/module-reference.md b/docs/build-modules/module-reference.md
index c2014371cf..31bd9bc895 100644
--- a/docs/build-modules/module-reference.md
+++ b/docs/build-modules/module-reference.md
@@ -20,6 +20,14 @@ This page is a reference for module developers. For step-by-step
 instructions, see [Write a Module](/build-modules/write-a-driver-module/) and
 [Deploy a Module](/build-modules/deploy-a-module/).
 
+## Module configuration {#module-configuration}
+
+For details on configuring modules and modular resources on a machine:
+
+- [Environment variables](#environment-variables) — custom env vars passed to your module
+- [Registry validation rules](#registry-validation-rules) — valid API and model identifier formats
+- [meta.json schema](#metajson-schema) — module metadata including visibility settings
+
 ## Module lifecycle
 
 Every module, local or registry, runs as a separate child process alongside
diff --git a/docs/build-modules/overview.md b/docs/build-modules/overview.md
index 9914978a93..bda49d4b44 100644
--- a/docs/build-modules/overview.md
+++ b/docs/build-modules/overview.md
@@ -8,8 +8,6 @@ description: "Understand the two kinds of modules and how to extend your machine
 aliases:
   - /operate/modules/
   - /operate/modules/advanced/
-  - /operate/reference/advanced-modules/
-  - /operate/reference/advanced-modules/create-subtype/
   - /build-modules/from-hardware-to-logic/
 ---
 
diff --git a/docs/hardware/common-components/add-a-camera.md b/docs/hardware/common-components/add-a-camera.md
index 4b6dfb8c7e..a61af3a261 100644
--- a/docs/hardware/common-components/add-a-camera.md
+++ b/docs/hardware/common-components/add-a-camera.md
@@ -8,7 +8,6 @@ description: "Add and configure a camera component, verify the feed, and capture
 date: "2025-01-30"
 aliases:
   - /operate/reference/components/camera/
-  - /operate/reference/components/camera/calibrate/
   - /build/foundation/add-a-camera/
   - /foundation/add-a-camera/
   - /hardware-components/add-a-camera/
@@ -334,6 +333,10 @@ Camera streams use a significant amount of CPU resources. The more CPU resources
 
 {{< /expand >}}
 
+## Camera calibration
+
+If you are using a camera with the motion service for arm movement or pick-and-place, you may need to calibrate it. Calibration computes the camera's intrinsic and distortion parameters so the motion service can project 2D image coordinates into 3D workspace coordinates accurately. See [Calibrate a camera for motion planning](/motion-planning/frame-system/camera-calibration/).
+
 ## Related
 
 - [Camera API reference](/reference/apis/components/camera/): full method documentation.
diff --git a/docs/hardware/configure-hardware.md b/docs/hardware/configure-hardware.md
index b3bbb8178a..bc03007dcc 100644
--- a/docs/hardware/configure-hardware.md
+++ b/docs/hardware/configure-hardware.md
@@ -69,7 +69,7 @@ If no model exists for your hardware, you can [write your own module](/build-mod
 
 <a id="browse-supported-hardware-by-component-api"></a>
 
-Browse all available components and services in the [Viam registry](https://app.viam.com/registry).
+Browse all available components and services in the [Viam registry](https://app.viam.com/registry). The registry also contains software modules that add capabilities beyond hardware drivers: vision and ML services, conversational and audio processing, device discovery, custom logic, and external integrations.
 
 ## Switching hardware without changing code
 
diff --git a/docs/hardware/multi-machine/overview.md b/docs/hardware/multi-machine/overview.md
index d097d093c6..88cf7df628 100644
--- a/docs/hardware/multi-machine/overview.md
+++ b/docs/hardware/multi-machine/overview.md
@@ -12,7 +12,6 @@ aliases:
   - /configure/parts/
   - /build/configure/parts/
   - /architecture/parts/
-  - /operate/reference/advanced-modules/custom-components-remotes/
   - /operate/reference/architecture/
   - /operate/reference/architecture/machine-to-machine-comms/
   - /operate/reference/architecture/parts/
diff --git a/docs/motion-planning/frame-system/camera-calibration.md b/docs/motion-planning/frame-system/camera-calibration.md
index a9e8da0122..23e741ab1a 100644
--- a/docs/motion-planning/frame-system/camera-calibration.md
+++ b/docs/motion-planning/frame-system/camera-calibration.md
@@ -9,6 +9,7 @@ aliases:
   - /work-cell-layout/calibrate-camera-to-robot/
   - /build/work-cell-layout/calibrate-camera-to-robot/
   - /motion-planning/camera-calibration/
+  - /operate/reference/components/camera/calibrate/
 ---
 
 Configuring a camera's frame tells the motion service where the camera
diff --git a/docs/reference/controls-package.md b/docs/reference/controls-package.md
new file mode 100644
index 0000000000..1e7b587165
--- /dev/null
+++ b/docs/reference/controls-package.md
@@ -0,0 +1,686 @@
+---
+linkTitle: "Control package"
+title: "Control package"
+weight: 60
+type: "docs"
+layout: "docs"
+description: "The control package implements PID feedback control loops for encoded motors, sensor-controlled bases, and custom components."
+date: "2022-01-01"
+no_list: true
+aliases:
+  - /operate/reference/controls-package/
+  - /internals/controls-package/
+---
+
+[Encoded motors](/reference/components/motor/encoded-motor/) and [sensor-controlled bases](/reference/components/base/sensor-controlled/) use a control loop implemented by `viam-server`.
+You can configure the `control_parameters` attribute for both component types to adjust the control loop.
+
+If you need to change or customize the control loops beyond the configurable parameters, or you want to add a control loop to a different component, you can use the `control` package from the RDK to [build your own PID control loop](#creating-and-using-a-pid-control-loop).
+
+The control package implements feedback control on an endpoint, which is usually the hardware you are trying to control.
+With the control package, you can design a control loop that monitors a process variable (PV) and compares it with a set point (SP).
+The control loop generates a control action to reduce the error value between the SP and PV (_SP - PV_) to zero.
+
+Control loops are represented in a diagrammatic style known as a block diagram.
+Each block represents a transfer function of a component.
+The control loop is broken down into successive "blocks" connected by their dependencies.
+
+## Creating and using a PID control loop
+
+A PID control loop computes a correction for the error value between SP and PV using three terms:
+
+- A _proportional_ term that is the current error
+- An _integral_ term that is the total cumulative error
+- A _derivative_ term that is the rate of change of the error
+
+By tuning the coefficients on each of these terms, you can adjust how your system converges towards the target value, how quickly it reaches the target, and how much it overshoots.
+
+The following functions are available for creating and using a control loop:
+
+<!-- prettier-ignore -->
+| Function | Description |
+| -------- | ----------- |
+| [`SetupPIDControlConfig`](#setuppidcontrolconfig) | Creates a [`PIDLoop`](#pidloop) that contains all the necessary attributes to run a control loop based on the specified [`Options`](#options). |
+| [`TunePIDLoop`](#tunepidloop) | Runs auto-tuning to find optimal PID values for the loop. |
+| [`StartControlLoop`](#startcontrolloop) | Starts the control loop in a background thread. |
+| [`CreateConstantBlock`](#createconstantblock) | Creates a control block of type `constant`. All control loops need at least one constant block representing the set point. |
+| [`UpdateConstantBlock`](#updateconstantblock) | Updates the value of a constant block to the new set point. |
+| [`CreateTrapzBlock`](#createtrapzblock) | Creates a control block of type `trapezoidalVelocityProfile`. Control loops that control position (for example, encoded motors) need a trapezoidal velocity profile block. |
+| [`UpdateTrapzBlock`](#updatetrapzblock) | Updates the attributes of a trapezoidal velocity profile block to a new max velocity. |
+
+### SetupPIDControlConfig
+
+Creates a [`PIDLoop`](#pidloop) object, which contains all the attributes related to a control loop that a controlled component needs, including the control config.
+If all PID values are zero and `NeedsAutoTuning` is set, the loop runs auto-tuning on creation.
+
+**Parameters:**
+
+- `pidVals` [(`[]PIDConfig`)](#pidconfig): The P, I, and D values for the control loop. If all are zero and `NeedsAutoTuning` is true, the loop auto-tunes and logs the calculated values.
+- `componentName` [(`string`)](https://pkg.go.dev/builtin#string): The name of the component that the PID loop controls.
+- `options` [(`Options`)](#options): Optional parameters to customize the control loop.
+- `c` [(`Controllable`)](#controllable): An interface that contains the functions to move the controlled component.
+- `logger` (`logging.Logger`): The logger of the controlled component.
+
+**Returns:**
+
+- [(`*PIDLoop`)](#pidloop): A pointer to a struct containing all relevant control loop attributes.
+- [(`error`)](https://pkg.go.dev/builtin#error): An error, if one occurred.
+
+```go
+pidVals := []control.PIDConfig{{
+  Type: "",
+  P: 1.0,
+  I: 2.0,
+  D: 0.0,
+}}
+
+options := control.Options{
+  PositionControlUsingTrapz: true,
+  LoopFrequency:             100.0,
+}
+
+pidLoop, err := control.SetupPIDControlConfig(pidVals, "motor_name", options, motor, motor.logger)
+```
+
+### TunePIDLoop
+
+Runs auto-tuning on the control loop to determine optimal PID values.
+Tuning runs in a background goroutine.
+When tuning completes, the component logs the calculated PID values and returns a `TunedPIDErr` prompting you to copy the values into your config.
+
+**Parameters:**
+
+- `ctx` [(`Context`)](https://pkg.go.dev/context): A context for the tuning operation.
+- `cancelFunc` [(`CancelFunc`)](https://pkg.go.dev/context#CancelFunc): A cancel function to stop tuning.
+
+**Returns:**
+
+- [(`error`)](https://pkg.go.dev/builtin#error): An error, if one occurred.
+
+```go
+cancelCtx, cancelFunc := context.WithCancel(context.Background())
+err := pidLoop.TunePIDLoop(cancelCtx, cancelFunc)
+```
+
+### StartControlLoop
+
+Starts running the PID control loop in a background thread to monitor and adjust the inputs to the controlled component.
+
+**Parameters:**
+
+- None
+
+**Returns:**
+
+- [(`error`)](https://pkg.go.dev/builtin#error): An error, if one occurred.
+
+```go
+err := pidLoop.StartControlLoop()
+```
+
+### CreateConstantBlock
+
+Creates a new control block of type `constant`.
+
+**Parameters:**
+
+- `ctx` [(`Context`)](https://pkg.go.dev/context): A context for the operation.
+- `name` [(`string`)](https://pkg.go.dev/builtin#string): The name of the constant block.
+- `constVal` [(`float64`)](https://pkg.go.dev/builtin#float64): The value of the new set point.
+
+**Returns:**
+
+- [(`BlockConfig`)](#blockconfig): The config for the newly created block.
+
+```go
+constBlock := control.CreateConstantBlock(context.Background(), "set_point", 10.0)
+```
+
+### UpdateConstantBlock
+
+Creates a new constant block and updates the running control loop to use it.
+
+**Parameters:**
+
+- `ctx` [(`Context`)](https://pkg.go.dev/context): A context for the operation.
+- `name` [(`string`)](https://pkg.go.dev/builtin#string): The name of the constant block.
+- `constVal` [(`float64`)](https://pkg.go.dev/builtin#float64): The value of the new set point.
+- `loop` (`*Loop`): The running control loop to update.
+
+**Returns:**
+
+- [(`error`)](https://pkg.go.dev/builtin#error): An error, if one occurred.
+
+```go
+err := control.UpdateConstantBlock(context.Background(), "set_point", 10.0, loop)
+```
+
+### CreateTrapzBlock
+
+Creates a new control block of type `trapezoidalVelocityProfile`.
+
+**Parameters:**
+
+- `ctx` [(`Context`)](https://pkg.go.dev/context): A context for the operation.
+- `name` [(`string`)](https://pkg.go.dev/builtin#string): The name of the trapezoidal block.
+- `maxVel` [(`float64`)](https://pkg.go.dev/builtin#float64): The max velocity for the controlled component.
+- `dependsOn` [(`[]string`)](https://pkg.go.dev/builtin#string): The names of the other control blocks that this block depends on. Usually the set point and the endpoint.
+
+**Returns:**
+
+- [(`BlockConfig`)](#blockconfig): The config for the newly created block.
+
+```go
+trapzBlock := control.CreateTrapzBlock(
+  context.Background(), "trapz", 4000.0, []string{"set_point", "endpoint"},
+)
+```
+
+### UpdateTrapzBlock
+
+Creates a new trapezoidal velocity profile block and updates the running control loop to use it.
+
+**Parameters:**
+
+- `ctx` [(`Context`)](https://pkg.go.dev/context): A context for the operation.
+- `name` [(`string`)](https://pkg.go.dev/builtin#string): The name of the trapezoidal block.
+- `maxVel` [(`float64`)](https://pkg.go.dev/builtin#float64): The max velocity for the controlled component. Must be non-zero.
+- `dependsOn` [(`[]string`)](https://pkg.go.dev/builtin#string): The names of the other control blocks that this block depends on.
+- `loop` (`*Loop`): The running control loop to update.
+
+**Returns:**
+
+- [(`error`)](https://pkg.go.dev/builtin#error): An error, if one occurred.
+
+```go
+err := control.UpdateTrapzBlock(
+  context.Background(), "trapz", 4000.0, []string{"set_point", "endpoint"}, loop,
+)
+```
+
+## Data types
+
+### PIDLoop
+
+`PIDLoop` contains all the attributes for setting up a PID control loop.
+[`SetupPIDControlConfig`](#setuppidcontrolconfig) creates this struct for you.
+
+```go
+type PIDLoop struct {
+  BlockNames   map[string][]string
+  PIDVals      []PIDConfig
+  TunedVals    *[]PIDConfig
+  ControlConf  *Config
+  ControlLoop  *Loop
+  Options      Options
+  Controllable Controllable
+}
+```
+
+| Field          | Type                  | Description                                                    |
+| -------------- | --------------------- | -------------------------------------------------------------- |
+| `BlockNames`   | `map[string][]string` | Maps block type names to the names of all blocks of that type. |
+| `PIDVals`      | `[]PIDConfig`         | The PID values for the control loop.                           |
+| `TunedVals`    | `*[]PIDConfig`        | Stores auto-tuned PID values after tuning completes.           |
+| `ControlConf`  | `*Config`             | The full control loop configuration.                           |
+| `ControlLoop`  | `*Loop`               | The running control loop instance, or `nil` if not started.    |
+| `Options`      | `Options`             | The options used to create this loop.                          |
+| `Controllable` | `Controllable`        | The component interface being controlled.                      |
+
+### PIDConfig
+
+`PIDConfig` holds the PID values for a control loop.
+For 2-dimensional control loops (such as a sensor-controlled base which controls both linear and angular velocity), the `Type` field is required and must be either `"linear_velocity"` or `"angular_velocity"`.
+For 1-dimensional control loops (such as an encoded motor), the `Type` field is not necessary.
+
+```go
+type PIDConfig struct {
+  Type string  `json:"type,omitempty"`
+  P    float64 `json:"p"`
+  I    float64 `json:"i"`
+  D    float64 `json:"d"`
+}
+```
+
+### Controllable
+
+`Controllable` is an interface that any component must implement to be controlled by a control loop.
+Encoded motors and sensor-controlled bases already implement this interface.
+
+- `State()` gets the current state of the endpoint (controlled component) and passes that information to the next iteration of the control loop.
+- `SetState()` takes the output from the latest iteration of the control loop and sets the state of the endpoint.
+
+For example, in an encoded motor, `State()` measures the current position of the motor so the next iteration knows how far it is from the goal.
+The control loop calculates the next power percentage, and `SetState()` applies that power to the motor.
+
+```go
+type Controllable interface {
+  SetState(ctx context.Context, state []*Signal) error
+  State(ctx context.Context) ([]float64, error)
+}
+```
+
+### Options
+
+`Options` contains optional parameters for customizing a control loop.
+All fields have defaults, so you only need to set the ones you want to change.
+
+<!-- prettier-ignore -->
+| Field | Type | Default | Description |
+| ----- | ---- | ------- | ----------- |
+| `PositionControlUsingTrapz` | `bool` | `false` | Adds a `trapezoidalVelocityProfile` block for position control. |
+| `SensorFeedback2DVelocityControl` | `bool` | `false` | Adds linear and angular blocks for sensor-controlled base velocity control. |
+| `DerivativeType` | `string` | `"backward1st1"` | The finite difference method for the derivative block. Options: `"backward1st1"`, `"backward1st2"`, `"backward1st3"`. |
+| `UseCustomConfig` | `bool` | `false` | Set to `true` to use `CompleteCustomConfig` instead of the auto-generated config. |
+| `CompleteCustomConfig` | `Config` | `Config{}` | A custom control config. Only used when `UseCustomConfig` is `true`. |
+| `NeedsAutoTuning` | `bool` | `false` | Set to `true` when all PID values are 0 and the loop should auto-tune. Set automatically when all PID values are 0. |
+| `LoopFrequency` | `float64` | `50.0` | The frequency (Hz) at which the control loop runs. |
+| `ControllableType` | `string` | `"motor_name"` | The type of component. Set to `"base_name"` when controlling a base. |
+
+```go
+type Options struct {
+  PositionControlUsingTrapz           bool
+  SensorFeedback2DVelocityControl     bool
+  DerivativeType                      string
+  UseCustomConfig                     bool
+  CompleteCustomConfig                Config
+  NeedsAutoTuning                     bool
+  LoopFrequency                       float64
+  ControllableType                    string
+}
+```
+
+The built-in control loop setup works with encoded motors and sensor-controlled bases.
+To use a different setup, set `UseCustomConfig` to `true` and `CompleteCustomConfig` to your custom `Config`.
+See [Control blocks](#control-blocks) for how to build individual blocks.
+
+### BlockConfig
+
+`BlockConfig` is the configuration for an individual control block.
+You need to build `BlockConfig` structs when using the `UseCustomConfig` option.
+Each block type requires different attributes, documented in [Control blocks](#control-blocks).
+
+```go
+type BlockConfig struct {
+  Name      string             `json:"name"`
+  Type      controlBlockType   `json:"type"`
+  Attribute utils.AttributeMap `json:"attributes"`
+  DependsOn []string           `json:"depends_on"`
+}
+```
+
+### Config
+
+`Config` is the top-level control loop configuration containing a list of blocks and a loop frequency.
+
+```go
+type Config struct {
+  Blocks    []BlockConfig `json:"blocks"`
+  Frequency float64       `json:"frequency"`
+}
+```
+
+## Control blocks
+
+The following example is a block diagram of a control loop that controls the speed of a motor.
+The motor has an encoder that reports its position.
+The position is derived to get speed, then filtered to remove noise.
+The error (_SP - PV_) is fed into the PID controller, which outputs a correction through a gain block to the endpoint.
+
+```text
++-------------+       +----------+       +----------+       +----------+
+|  SetPoint   +------>|   Sum    +------>|   PID    +------>| Endpoint |
+| (constant)  |       |          |       |          |       |  (motor) |
++-------------+       +-----^----+       +----------+       +----+-----+
+                             |                                    |
+                       +-----+----+       +----------+            |
+                       |  Filter  |<------+ Derive   |<-----------+
+                       |          |       |          |
+                       +----------+       +----------+
+```
+
+The `frequency` field in the control config sets how often the loop runs (in Hz).
+Higher frequencies produce smaller errors at each step and smoother control.
+
+### Common block fields
+
+All blocks share these fields:
+
+- `name`: A unique name used to reference the block in `depends_on` lists.
+- `type`: The block type (see supported types below).
+- `attributes`: Type-specific configuration.
+- `depends_on`: List of block names this block takes input from.
+
+### Gain
+
+Multiplies the input signal by a constant gain value: `S_out = S_in * gain`.
+
+```json
+{
+  "name": "gain",
+  "type": "gain",
+  "attributes": {
+    "gain": 0.00392156862
+  },
+  "depends_on": ["PID"]
+}
+```
+
+The default gain of `0.00392156862` (1/255) scales the PID output to a 0-1 PWM range for standard 8-bit PWM boards.
+
+### Constant
+
+Outputs a constant signal value, typically used as the set point: `S_out = constant_val`.
+
+```json
+{
+  "name": "set_point",
+  "type": "constant",
+  "attributes": {
+    "constant_val": 0.0
+  }
+}
+```
+
+### Endpoint
+
+Represents the physical hardware being controlled.
+The endpoint reads state from the hardware and applies control outputs to it.
+
+Set the attribute key to `"motor_name"` for motors or `"base_name"` for bases.
+
+```json
+{
+  "name": "endpoint",
+  "type": "endpoint",
+  "attributes": {
+    "motor_name": "my-motor"
+  },
+  "depends_on": ["gain"]
+}
+```
+
+### PID
+
+The PID block computes a correction from the error signal using proportional, integral, and derivative terms:
+
+`u(t) = Kp * e(t) + Ki * integral(e(t)) * dt + Kd * (de(t)/dt)`
+
+Where Kp, Ki, and Kd are the PID gains, e(t) is the error at time t, and dt is the time between steps.
+
+The `PIDSets` attribute takes an array of [`PIDConfig`](#pidconfig) objects.
+Use one PID set for single-axis control (encoded motor) or two for dual-axis control (sensor-controlled base with linear and angular velocity).
+
+```json
+{
+  "name": "PID",
+  "type": "PID",
+  "attributes": {
+    "PIDSets": [{ "p": 1.0, "i": 0.5, "d": 0.0 }],
+    "limit_up": 255.0,
+    "limit_lo": -255.0,
+    "int_sat_lim_up": 255.0,
+    "int_sat_lim_lo": -255.0,
+    "tune_ssr_value": 2.0,
+    "tune_method": "ziegerNicholsPI",
+    "tune_step_pct": 0.35
+  },
+  "depends_on": ["sum"]
+}
+```
+
+<!-- prettier-ignore -->
+| Attribute | Type | Description |
+| --------- | ---- | ----------- |
+| `PIDSets` | `[]*PIDConfig` | Array of PID gain configurations. One per axis of control. |
+| `limit_up` | `float64` | Maximum PID output value. Default: `255.0`. |
+| `limit_lo` | `float64` | Minimum PID output value. Default: `0.0`. |
+| `int_sat_lim_up` | `float64` | Upper integral anti-windup limit. Default: `255.0`. |
+| `int_sat_lim_lo` | `float64` | Lower integral anti-windup limit. Default: `0.0`. |
+| `tune_ssr_value` | `float64` | Threshold for detecting steady state during auto-tuning. Sensible range: 1.0 to 2.0. |
+| `tune_method` | `string` | Auto-tuning method. Default: `"ziegerNicholsPID"`. See [tuning methods](#tuning-methods). |
+| `tune_step_pct` | `float64` | Step size as a fraction of the output range for auto-tuning relay tests. |
+
+#### Tuning methods
+
+To auto-tune, set all PID values to 0.
+The control loop records the step response and uses the relay method to estimate the ultimate gain (Ku) and oscillation period (Tu), then calculates gains using the selected method:
+
+| Method                       | Description                            |
+| ---------------------------- | -------------------------------------- |
+| `ziegerNicholsPI`            | Ziegler-Nichols PI tuning              |
+| `ziegerNicholsPID`           | Ziegler-Nichols PID tuning (default)   |
+| `ziegerNicholsPD`            | Ziegler-Nichols PD tuning              |
+| `ziegerNicholsSomeOvershoot` | Ziegler-Nichols with reduced overshoot |
+| `ziegerNicholsNoOvershoot`   | Ziegler-Nichols with no overshoot      |
+| `cohenCoonsPI`               | Cohen-Coons PI tuning                  |
+| `cohenCoonsPID`              | Cohen-Coons PID tuning                 |
+| `tyreusLuybenPI`             | Tyreus-Luyben PI tuning                |
+| `tyreusLuybenPID`            | Tyreus-Luyben PID tuning               |
+
+### Encoder to RPM
+
+Converts encoder counts to RPM using the pulses-per-revolution value of the encoder.
+
+```json
+{
+  "name": "encoder_to_rpm",
+  "type": "encoderToRpm",
+  "attributes": {
+    "PulsesPerRevolution": 14
+  },
+  "depends_on": ["endpoint"]
+}
+```
+
+### Sum
+
+Sums input signals according to a `sum_string` that specifies the sign of each input.
+Each character is `+` or `-`, one per dependency in order.
+
+```json
+{
+  "name": "sum",
+  "type": "sum",
+  "attributes": {
+    "sum_string": "+-"
+  },
+  "depends_on": ["set_point", "endpoint"]
+}
+```
+
+In this example, the output is `set_point - endpoint`, computing the error between the desired and actual values.
+
+### Trapezoidal velocity profile
+
+Position control of a motor can use a trapezoidal velocity profile generator.
+When a new set point arrives, this block generates a velocity profile with three phases: acceleration, constant speed, and deceleration.
+
+The profile is dynamically adjusted during deceleration to keep the end position within the position window.
+The block also acts as a deadband controller when the target position is reached, preventing the motor from moving outside the window.
+
+```json
+{
+  "name": "trapz",
+  "type": "trapezoidalVelocityProfile",
+  "attributes": {
+    "max_vel": 4000.0,
+    "max_acc": 30000.0,
+    "pos_window": 10.0,
+    "kpp_gain": 0.45
+  },
+  "depends_on": ["set_point", "endpoint"]
+}
+```
+
+<!-- prettier-ignore -->
+| Attribute | Type | Description |
+| --------- | ---- | ----------- |
+| `max_vel` | `float64` | Maximum velocity. |
+| `max_acc` | `float64` | Maximum acceleration. |
+| `pos_window` | `float64` | Deadband window around the target position. |
+| `kpp_gain` | `float64` | Proportional gain for position error in the deadband controller. |
+
+### Derivative
+
+Computes the derivative of the input signal using a finite difference method.
+
+```json
+{
+  "name": "derivative",
+  "type": "derivative",
+  "attributes": {
+    "derive_type": "backward1st1"
+  },
+  "depends_on": ["endpoint"]
+}
+```
+
+| Attribute     | Type     | Description                                                                                                                                              |
+| ------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `derive_type` | `string` | The finite difference method. Options: `"backward1st1"`, `"backward1st2"`, `"backward1st3"`. Higher orders use more past samples for smoother estimates. |
+
+### Filter
+
+Applies a digital filter to the input signal to remove noise.
+Supports FIR (finite impulse response) and IIR (infinite impulse response) filters.
+
+```json
+{
+  "name": "filter",
+  "type": "filter",
+  "attributes": {
+    "filter_type": "lowpass"
+  },
+  "depends_on": ["derivative"]
+}
+```
+
+## Examples
+
+### Using SetupPIDControlConfig
+
+Set up and tune a control loop using [`SetupPIDControlConfig`](#setuppidcontrolconfig):
+
+```go
+// Set the options for your component
+options := control.Options{
+  LoopFrequency: 100.0,
+}
+
+// Create PID values. All zeros triggers auto-tuning.
+controlParams := []control.PIDConfig{{
+  Type: "",
+  P:    0.0,
+  I:    0.0,
+  D:    0.0,
+}}
+
+// Enable auto-tuning if all PID values are 0
+if controlParams[0].NeedsAutoTuning() {
+  options.NeedsAutoTuning = true
+}
+
+// Create the control config and tune if necessary
+pidLoop, err := control.SetupPIDControlConfig(
+  controlParams, "component", options, component, component.logger,
+)
+if err != nil {
+  return err
+}
+
+// Useful attributes after setup
+controlLoopConfig := pidLoop.ControlConf
+loop := pidLoop.ControlLoop
+blockNames := pidLoop.BlockNames
+```
+
+### Using a custom control config
+
+Set up a control loop with a custom block configuration using the `UseCustomConfig` and `CompleteCustomConfig` options:
+
+```go
+// Create a custom control config
+controlConfig := control.Config{
+  Blocks: []control.BlockConfig{
+    {
+      Name: "set_point",
+      Type: "constant",
+      Attribute: rdkutils.AttributeMap{
+        "constant_val": 0.0,
+      },
+    },
+    {
+      Name: "sum",
+      Type: "sum",
+      Attribute: rdkutils.AttributeMap{
+        "sum_string": "+-",
+      },
+      DependsOn: []string{"set_point", "endpoint"},
+    },
+    {
+      Name: "PID",
+      Type: "PID",
+      Attribute: rdkutils.AttributeMap{
+        "int_sat_lim_lo": -255.0,
+        "int_sat_lim_up": 255.0,
+        "PIDSets":        []*control.PIDConfig{{P: 1.0, I: 0.5, D: 0.0}},
+        "limit_lo":       -255.0,
+        "limit_up":       255.0,
+        "tune_method":    "ziegerNicholsPI",
+        "tune_ssr_value": 2.0,
+        "tune_step_pct":  0.35,
+      },
+      DependsOn: []string{"sum"},
+    },
+    {
+      Name: "gain",
+      Type: "gain",
+      Attribute: rdkutils.AttributeMap{
+        "gain": 0.00392156862,
+      },
+      DependsOn: []string{"PID"},
+    },
+    {
+      Name: "endpoint",
+      Type: "endpoint",
+      Attribute: rdkutils.AttributeMap{
+        "motor_name": "my-motor",
+      },
+      DependsOn: []string{"gain"},
+    },
+  },
+  Frequency: 100.0,
+}
+
+// Set the options to use the custom config
+options := control.Options{
+  UseCustomConfig:      true,
+  CompleteCustomConfig: controlConfig,
+}
+
+// Create PID parameters for auto-tuning
+controlParams := []control.PIDConfig{{
+  Type: "",
+  P:    0.0,
+  I:    0.0,
+  D:    0.0,
+}}
+
+if controlParams[0].NeedsAutoTuning() {
+  options.NeedsAutoTuning = true
+}
+
+// Create and configure the PID loop
+pidLoop, err := control.SetupPIDControlConfig(
+  controlParams, "my-motor", options, component, component.logger,
+)
+if err != nil {
+  return err
+}
+
+// Useful attributes after setup
+controlLoopConfig := pidLoop.ControlConf
+loop := pidLoop.ControlLoop
+blockNames := pidLoop.BlockNames
+```
diff --git a/docs/reference/device-setup/rpi-setup.md b/docs/reference/device-setup/rpi-setup.md
index 34eab51d7c..8a967907dd 100644
--- a/docs/reference/device-setup/rpi-setup.md
+++ b/docs/reference/device-setup/rpi-setup.md
@@ -22,8 +22,6 @@ date: "2022-01-01"
 # updated: ""  # When the content was last entirely checked
 ---
 
-{{<youtube embed_url="https://www.youtube-nocookie.com/embed/drl2p2of-qA">}}
-
 We recommend using Viam on a 64-bit Linux distribution.
 Support for older Raspberry Pis running on 32-bit ARM v7 is in beta.
 
@@ -186,6 +184,37 @@ While the Imager is flashing your microSD card, we recommend reading [How to thi
 2.  Place the SD card into your Raspberry Pi and boot the Pi by plugging it in to an outlet.
     A red LED will turn on to indicate that the Pi is connected to power.
 
+## Update WiFi credentials
+
+If you move your Raspberry Pi to a different WiFi network, you need to update the WiFi credentials.
+
+You can update the WiFi configuration by creating a new `wpa_supplicant.conf` file on the boot partition:
+
+1. Remove the microSD card from the Pi and plug it into your computer.
+1. Create a plain text file called `wpa_supplicant.conf` on the boot partition.
+1. Paste the following into the file, replacing the SSID and password values with your credentials.
+   Use UNIX (LF) line breaks.
+
+   ```bash {class="line-numbers linkable-line-numbers"}
+   ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
+   update_config=1
+   country=us
+
+   network={
+    ssid="Name of your wireless LAN"
+    psk="Password for your wireless LAN"
+    priority=10
+   }
+   ```
+
+   You can duplicate the `network` section to add multiple WiFi networks (for example, work and home).
+   The `priority` attribute is optional: higher numbers are preferred when multiple configured networks are available.
+
+1. Save the file and eject the microSD card.
+1. Put the microSD card back into the Pi and boot it.
+
+The Pi reads and removes `wpa_supplicant.conf` on boot, updating the stored WiFi credentials.
+
 ## Next steps
 
 Continue setting up `viam-server` on your Raspberry Pi in [the Viam app](https://app.viam.com/):
diff --git a/docs/reference/services/motion/_index.md b/docs/reference/services/motion/_index.md
index 87c994aba1..be547ad1ed 100644
--- a/docs/reference/services/motion/_index.md
+++ b/docs/reference/services/motion/_index.md
@@ -165,10 +165,10 @@ The [motion service API](/reference/apis/services/motion/) supports the followin
 
 You can test motion on your machine from the [**CONTROL** tab](/monitor/).
 
-Enter X and Y coordinates for your destination in meters, then click **Execute** to issue a `MoveOnMap()` request.
+Enter x and y coordinates to move your machine to, then click the **Move** button to issue a `MoveOnMap()` request.
 
 {{< alert title="Info" color="info" >}}
 
-If you leave the **Plan deviation (m)** field blank, `MoveOnMap()` uses the motion service default of 1.0 m.
+The `plan_deviation_m` for `MoveOnMap()` on calls issued from the **CONTROL** tab is 0.5 m.
 
 {{< /alert >}}
diff --git a/static/include/services/apis/generated/motion.md b/static/include/services/apis/generated/motion.md
index b0613edd7f..0e843f96cb 100644
--- a/static/include/services/apis/generated/motion.md
+++ b/static/include/services/apis/generated/motion.md
@@ -16,7 +16,7 @@ The motion service takes the volumes associated with all configured machine comp
 **Parameters:**
 
 - `component_name` ([str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str)) (required): The `ResourceName` of the piece of the robot that should arrive at the destination. Note that `move` moves the distal end of the component to the destination. For example, when moving a robotic arm, the piece that will arrive at the destination is the end effector attachment point, not the base of the arm.
-- `destination` ([viam.proto.common.PoseInFrame](https://python.viam.dev/autoapi/viam/proto/common/index.html#viam.proto.common.PoseInFrame)) (required): Describes where the `component_name` frame should be moved to. Can be any pose, from the perspective of any component whose location is configured as a [`frame`](/operate/reference/services/frame-system/).
+- `destination` ([viam.proto.common.PoseInFrame](https://python.viam.dev/autoapi/viam/proto/common/index.html#viam.proto.common.PoseInFrame)) (required): Describes where the `component_name` frame should be moved to. Can be any pose, from the perspective of any component whose location is configured as a [`frame`](/motion-planning/frame-system/).
 - `world_state` ([viam.proto.common.WorldState](https://python.viam.dev/autoapi/viam/proto/common/index.html#viam.proto.common.WorldState)) (optional): Data structure specifying information about the world around the machine.
   Used to augment the motion solving process.
   `world_state` includes obstacles and transforms:
@@ -37,7 +37,7 @@ The motion service takes the volumes associated with all configured machine comp
     Transforms can be used to account for geometries that are attached to the robot but not configured as robot components.
     For example, you could use a transform to represent the volume of a marker held in your machine's gripper.
     Transforms are not added to the config or carried into later processes.
-- `constraints` ([viam.proto.service.motion.Constraints](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.Constraints)) (optional): Pass in [motion constraints](/operate/reference/services/motion/constraints/). By default, motion is unconstrained with the exception of obstacle avoidance.
+- `constraints` ([viam.proto.service.motion.Constraints](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.Constraints)) (optional): Pass in [motion constraints](/reference/services/motion/constraints/). By default, motion is unconstrained with the exception of obstacle avoidance.
 - `extra` (Mapping[[str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str), Any]) (optional): Extra options to pass to the underlying RPC call.
 - `timeout` ([float](https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex)) (optional): An option to set how long to wait (in seconds) before calling a time-out and closing the underlying RPC call.
 
@@ -369,7 +369,7 @@ Make sure the [movement sensor](/operate/reference/components/movement-sensor/)
 {{< alert title="Stability Notice" color="alert" >}}
 
 The `heading` parameter is experimental.
-Specifying `heading` in a request to `MoveOnGlobe` is not currently recommended if the minimum turning radius of your component is greater than zero, as this combination may cause high latency in the [motion planning algorithms](/operate/reference/services/motion/algorithms/).
+Specifying `heading` in a request to `MoveOnGlobe` is not currently recommended if the minimum turning radius of your component is greater than zero, as this combination may cause high latency in the [motion planning algorithms](/reference/services/motion/algorithms/).
 
 Specifying `obstacles` in a request to `MoveOnGlobe()` will cause an error if you configure a `"translation"` in the `"geometries"` of any of the `GeoGeometry` objects.
 Translation in obstacles is not supported by the [navigation service](/operate/reference/services/navigation/).
@@ -534,7 +534,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### GetPose
 
-`GetPose` gets the location and orientation of a component within the [frame system](/operate/reference/services/frame-system/).
+`GetPose` gets the location and orientation of a component within the [frame system](/motion-planning/frame-system/).
 The return type of this function is a `PoseInFrame` describing the pose of the specified component with respect to the specified destination frame.
 You can use the `supplemental_transforms` argument to augment the machine's existing frame system with supplemental frames.
 

From 7a1a289103508afc10e0462ea9a14e2f5588bc4a Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 12:11:35 -0400
Subject: [PATCH 3/8] Fix markdownlint and prettier issues in
 advanced-patterns.md

Add blank line before list after "Keep in mind:" paragraph.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 docs/build-modules/advanced-patterns.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/docs/build-modules/advanced-patterns.md b/docs/build-modules/advanced-patterns.md
index f4a822f0b8..c623191a28 100644
--- a/docs/build-modules/advanced-patterns.md
+++ b/docs/build-modules/advanced-patterns.md
@@ -58,11 +58,13 @@ Viam uses [protocol buffers](https://protobuf.dev/) for API definition. To defin
    {{% /alert %}}
 
 4. Write the proto methods in a `<API name>.proto` file inside `src/proto/`. For reference:
+
    - [Example modular component proto file](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/proto/gizmo.proto)
    - [Example modular service proto file](https://github.com/viam-labs/speech-service-api/blob/main/src/proto/speech.proto)
    - [Built-in Viam resource proto files](https://github.com/viamrobotics/api/tree/main/proto/viam)
 
 5. Define the proto methods in Python or Go in a file called `api.py` or `api.go`:
+
    - [Example component in Python](https://github.com/viamrobotics/viam-python-sdk/blob/main/examples/complex_module/src/gizmo/api.py)
    - [Example service in Python](https://github.com/viam-labs/speech-service-api/blob/main/src/speech_service_api/api.py)
 
@@ -75,6 +77,7 @@ Viam uses [protocol buffers](https://protobuf.dev/) for API definition. To defin
 Once your API is defined, [create a model that implements it](/build-modules/write-a-driver-module/).
 
 Keep in mind:
+
 - You cannot use [SDKs](/reference/sdks/) to call your new API unless you build out the client to support it. Write code against the API in the language you used to define it.
 - You need a local copy of the module code on whatever machine runs client code against it.
 - Import the API definition from the module directory. For example, in Python: `from path.to.module.src.gizmo import Gizmo`.

From 90b35f3e84914dbae5fce73d4601d3f195dfb163 Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 15:09:12 -0400
Subject: [PATCH 4/8] Remove SLAM glossary entry and tooltip references

SLAM content is being removed entirely. Delete the glossary file and
replace tooltip references with plain text on the 2 pages that link
to it.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 docs/reference/glossary/slam.md                      | 12 ------------
 docs/reference/sdks/use-extra-params.md              |  2 +-
 .../projects/integrating-viam-with-openai.md         |  2 +-
 3 files changed, 2 insertions(+), 14 deletions(-)
 delete mode 100644 docs/reference/glossary/slam.md

diff --git a/docs/reference/glossary/slam.md b/docs/reference/glossary/slam.md
deleted file mode 100644
index 9246dad02c..0000000000
--- a/docs/reference/glossary/slam.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: SLAM
-id: slam
-full_link: /operate/reference/services/slam/
-short_description: Simultaneous Localization And Mapping (SLAM) algorithms use data from a machine's sensors to generate a map of the environment and determine the machine's position within it.
-aliases:
-  - /dev/reference/glossary/slam/
----
-
-SLAM (Simultaneous Localization and Mapping) algorithms use data from a machine's sensors, like LiDARs, cameras, and movement sensors, to generate a map of the environment and determine the machine's position within it.
-
-For more information, see [SLAM](/operate/reference/services/slam/).
diff --git a/docs/reference/sdks/use-extra-params.md b/docs/reference/sdks/use-extra-params.md
index 46bcd5bb6c..65b9a026d2 100644
--- a/docs/reference/sdks/use-extra-params.md
+++ b/docs/reference/sdks/use-extra-params.md
@@ -21,7 +21,7 @@ How to [use](#use) and [define](#define) the `extra` parameters that many {{< gl
 
 You can use `extra` parameters with modular {{< glossary_tooltip term_id="resource" text="resource" >}} implementations that are _models_ of built-in resource types.
 
-For example, a new model of [sensor](/hardware/common-components/add-a-sensor/), or a new model of {{< glossary_tooltip term_id="slam" text="SLAM" >}} service.
+For example, a new model of [sensor](/hardware/common-components/add-a-sensor/), or a new model of SLAM service.
 
 The `extra` parameters in that built-in resource type's [API](/reference/apis/) allow users to pass information to a resource's driver that isn't specified as a parameter for all models of the resource type.
 This is necessary to keep the API of resource types consistent across, for example, all models of [motor](/hardware/common-components/add-a-motor/) or all models of [camera](/hardware/common-components/add-a-camera/).
diff --git a/docs/tutorials/projects/integrating-viam-with-openai.md b/docs/tutorials/projects/integrating-viam-with-openai.md
index e5c89ddbdb..1f455242f0 100644
--- a/docs/tutorials/projects/integrating-viam-with-openai.md
+++ b/docs/tutorials/projects/integrating-viam-with-openai.md
@@ -421,7 +421,7 @@ Some ideas:
 
 - Make the voice recognition software listen in the background, so the robot can move and interact with the world while listening and responding.
 - Integrate another ML model that is used to follow a human (when told to do so).
-- Add Lidar and integrate Viam's {{< glossary_tooltip term_id="slam" text="SLAM service" >}} to map the world around it.
+- Add Lidar and integrate a SLAM service to map the world around it.
 - Use Viam's [Data Management](/data/capture-sync/capture-and-sync-data/) to collect environmental data and use this data to train new ML models that allow the robot to improve its functionality.
 
 We'd love to see where you decide to take this. If you build your own companion robot, let us and others know on the [Community Discord](https://discord.gg/viam).

From 2439a475c9e40385db009946ec0dca059b762fb4 Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 15:33:40 -0400
Subject: [PATCH 5/8] Remove SLAM glossary tooltips from generated motion API
 includes

The motion service docs reference SLAM via glossary tooltips. Since
the SLAM glossary entry is removed, replace tooltips with plain text
in the static include files.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 static/include/services/apis/generated/motion-table.md        | 2 +-
 static/include/services/apis/generated/motion.md              | 4 ++--
 .../services/apis/overrides/protos/motion.MoveOnMap.md        | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/static/include/services/apis/generated/motion-table.md b/static/include/services/apis/generated/motion-table.md
index 3c03fd5dbf..dfa35cfc38 100644
--- a/static/include/services/apis/generated/motion-table.md
+++ b/static/include/services/apis/generated/motion-table.md
@@ -2,7 +2,7 @@
 | Method Name | Description |
 | ----------- | ----------- |
 | [`Move`](/reference/apis/services/motion/#move) | The `Move` method is the primary way to move multiple components, or to move any object to any other location. |
-| [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) | Move a base component to a destination pose on a {{< glossary_tooltip term_id="slam" text="SLAM" >}} map. |
+| [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) | Move a base component to a destination pose on a SLAM map. |
 | [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) | Move a base component to a destination GPS point, represented in geographic notation _(latitude, longitude)_. |
 | [`GetPose`](/reference/apis/services/motion/#getpose) | `GetPose` gets the location and orientation of a component within the frame system. |
 | [`StopPlan`](/reference/apis/services/motion/#stopplan) | Stop a base component being moved by an in progress `MoveOnGlobe` or `MoveOnMap` call. |
diff --git a/static/include/services/apis/generated/motion.md b/static/include/services/apis/generated/motion.md
index 0e843f96cb..e4bb4d5954 100644
--- a/static/include/services/apis/generated/motion.md
+++ b/static/include/services/apis/generated/motion.md
@@ -158,7 +158,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### MoveOnMap
 
-Move a [base](/operate/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a {{< glossary_tooltip term_id="slam" text="SLAM" >}} map.
+Move a [base](/operate/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a SLAM map.
 
 `MoveOnMap()` is non blocking, meaning the motion service will move the component to the destination [pose](/motion-planning/reference/orientation-vectors/) after `MoveOnMap()` returns.
 
@@ -170,7 +170,7 @@ If you specify a goal pose and the robot's current position is already within th
 
 You can monitor the progress of the `MoveOnMap()` call by querying `GetPlan()` and `ListPlanStatuses()`.
 
-Use the machine's position reported by the {{< glossary_tooltip term_id="slam" text="SLAM" >}} service to check the location of the machine.
+Use the machine's position reported by the SLAM service to check the location of the machine.
 
 `MoveOnMap()` is intended for use with the [navigation service](/operate/reference/services/navigation/), providing autonomous indoor navigation for rover [bases](/operate/reference/components/base/).
 
diff --git a/static/include/services/apis/overrides/protos/motion.MoveOnMap.md b/static/include/services/apis/overrides/protos/motion.MoveOnMap.md
index a5a0bbcad4..d60847e4cd 100644
--- a/static/include/services/apis/overrides/protos/motion.MoveOnMap.md
+++ b/static/include/services/apis/overrides/protos/motion.MoveOnMap.md
@@ -1,4 +1,4 @@
-Move a [base](/operate/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a {{< glossary_tooltip term_id="slam" text="SLAM" >}} map.
+Move a [base](/operate/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a SLAM map.
 
 `MoveOnMap()` is non blocking, meaning the motion service will move the component to the destination [pose](/motion-planning/reference/orientation-vectors/) after `MoveOnMap()` returns.
 
@@ -10,7 +10,7 @@ If you specify a goal pose and the robot's current position is already within th
 
 You can monitor the progress of the `MoveOnMap()` call by querying `GetPlan()` and `ListPlanStatuses()`.
 
-Use the machine's position reported by the {{< glossary_tooltip term_id="slam" text="SLAM" >}} service to check the location of the machine.
+Use the machine's position reported by the SLAM service to check the location of the machine.
 
 `MoveOnMap()` is intended for use with the [navigation service](/operate/reference/services/navigation/), providing autonomous indoor navigation for rover [bases](/operate/reference/components/base/).
 

From d70c2e7b8153f4c6756eb8bcd180de95ab2f5d9c Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 15:57:20 -0400
Subject: [PATCH 6/8] Fix all remaining body-text operate/ links and SLAM
 references
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Apply operate/ → new-IA mapping to all static/include/ files (81 files)
- Update remaining service body-text links in 7 docs files (operate/reference/services/X/ → /reference/services/X/)
- Strip SLAM service link from motion API includes (slam pages deleted)
- Remove broken Desk Safari tutorial link from try-example include

After this change, all internal htmltest checks pass locally.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 docs/build-modules/write-a-cpp-module.md      |  2 +-
 docs/reference/apis/services/base-rc.md       |  2 +-
 docs/reference/apis/services/discovery.md     |  2 +-
 docs/reference/apis/services/generic.md       |  2 +-
 docs/reference/apis/services/navigation.md    |  2 +-
 docs/tutorials/control/gamepad.md             |  2 +-
 .../services/navigate-with-rover-base.md      |  8 ++--
 static/include/app/apis/generated/app.md      | 10 ++---
 .../apis/overrides/protos/app.CreateKey.md    |  2 +-
 .../apis/overrides/protos/app.DeleteKey.md    |  2 +-
 .../overrides/protos/app.GetRobotAPIKeys.md   |  2 +-
 .../overrides/protos/app.MarkPartAsMain.md    |  2 +-
 .../apis/overrides/protos/app.RotateKey.md    |  2 +-
 static/include/applications.md                |  2 +-
 .../include/components/apis/generated/arm.md  |  6 +--
 .../components/apis/generated/audio_in.md     |  4 +-
 .../components/apis/generated/audio_out.md    |  4 +-
 .../include/components/apis/generated/base.md |  4 +-
 .../components/apis/generated/board.md        |  6 +--
 .../components/apis/generated/camera.md       |  4 +-
 .../components/apis/generated/encoder.md      |  4 +-
 .../components/apis/generated/gantry.md       |  4 +-
 .../apis/generated/generic_component.md       |  4 +-
 .../components/apis/generated/gripper.md      |  6 +--
 .../apis/generated/input_controller.md        |  4 +-
 .../components/apis/generated/motor.md        |  4 +-
 .../apis/generated/movement_sensor.md         |  4 +-
 .../components/apis/generated/sensor.md       |  4 +-
 .../components/apis/generated/servo.md        |  4 +-
 .../go.board.AnalogNames.string.return.md     |  2 +-
 ...ard.DigitalInterruptNames.string.return.md |  2 +-
 .../methods/go.board.GPIOPinByName.name.md    |  2 +-
 .../overrides/protos/arm.GetGeometries.md     |  4 +-
 .../overrides/protos/arm.GetKinematics.md     |  2 +-
 .../protos/audio_in.GetGeometries.md          |  4 +-
 .../protos/audio_out.GetGeometries.md         |  4 +-
 .../overrides/protos/base.GetGeometries.md    |  4 +-
 .../overrides/protos/board.GetGeometries.md   |  4 +-
 .../overrides/protos/button.GetGeometries.md  |  4 +-
 .../overrides/protos/camera.GetGeometries.md  |  4 +-
 .../overrides/protos/encoder.GetGeometries.md |  4 +-
 .../overrides/protos/gantry.GetGeometries.md  |  4 +-
 .../protos/generic_component.GetGeometries.md |  4 +-
 .../overrides/protos/gripper.GetGeometries.md |  4 +-
 .../overrides/protos/gripper.GetKinematics.md |  2 +-
 .../protos/input_controller.GetGeometries.md  |  4 +-
 .../overrides/protos/motor.GetGeometries.md   |  4 +-
 .../protos/movement_sensor.GetGeometries.md   |  4 +-
 .../protos/power_sensor.GetGeometries.md      |  4 +-
 .../overrides/protos/sensor.GetGeometries.md  |  4 +-
 .../overrides/protos/servo.GetGeometries.md   |  4 +-
 static/include/components/base-sensor.md      |  4 +-
 .../include/components/board/board-analogs.md |  2 +-
 static/include/components/motor-sensor.md     |  2 +-
 .../test-control/generic-control.md           |  2 +-
 .../components/test-control/switch-control.md |  2 +-
 .../include/components/troubleshoot/camera.md |  2 +-
 static/include/create-your-own-mr.md          |  2 +-
 static/include/data/capture-supported.md      | 10 ++---
 static/include/install/install-linux-aarch.md |  2 +-
 static/include/install/install-linux.md       |  2 +-
 static/include/install/try-example.md         |  2 -
 static/include/micro-create-your-own.md       |  2 +-
 static/include/micro-rdk-hardware.md          |  4 +-
 static/include/program/authenticate.md        |  2 +-
 static/include/services/apis/fleet.md         |  2 +-
 .../include/services/apis/generated/motion.md | 40 +++++++++----------
 .../services/apis/generated/navigation.md     |  2 +-
 .../include/services/apis/generated/slam.md   |  2 +-
 .../methods/go.motion.Move.constraints.md     |  2 +-
 .../methods/go.motion.Move.destination.md     |  2 +-
 .../methods/go.motion.MoveOnGlobe.req.md      |  4 +-
 .../methods/go.motion.MoveOnMap.req.md        |  4 +-
 .../go.slam.Properties.Properties.return.md   |  2 +-
 .../methods/python.motion.get_pose.after.md   |  2 +-
 .../methods/python.motion.move.constraints.md |  2 +-
 .../methods/python.motion.move.destination.md |  2 +-
 ...thon.motion.move_on_globe.configuration.md |  2 +-
 ...tion.move_on_globe.movement_sensor_name.md |  2 +-
 ...python.motion.move_on_map.configuration.md |  2 +-
 ...on.motion.move_on_map.slam_service_name.md |  2 +-
 .../apis/overrides/protos/motion.GetPlan.md   |  2 +-
 .../apis/overrides/protos/motion.GetPose.md   |  2 +-
 .../overrides/protos/motion.MoveOnGlobe.md    | 12 +++---
 .../apis/overrides/protos/motion.MoveOnMap.md |  8 ++--
 .../apis/overrides/protos/motion.StopPlan.md  |  2 +-
 .../protos/navigation.GetObstacles.md         |  2 +-
 static/include/snippet/visualize.md           |  2 +-
 88 files changed, 164 insertions(+), 166 deletions(-)

diff --git a/docs/build-modules/write-a-cpp-module.md b/docs/build-modules/write-a-cpp-module.md
index 4dfe684bb5..0b310ba439 100644
--- a/docs/build-modules/write-a-cpp-module.md
+++ b/docs/build-modules/write-a-cpp-module.md
@@ -61,7 +61,7 @@ For example, the [sensor API](/reference/apis/components/sensor/) has a `GetRead
 If instead of just getting readings, you actually have an encoder and need to be able to reset the zero position, use the [encoder API](/reference/apis/components/encoder/) so you can define functionality behind the `GetPosition` and `ResetPosition` methods.
 
 In addition to the list of methods, another reason to choose one API over another is how certain APIs fit into the Viam ecosystem.
-For example, though you could technically implement a GPS as a sensor with just the `GetReadings` method, if you implement it as a movement sensor then you have access to methods like `GetCompassHeading` which allow you to use your GPS module with the [navigation service](/operate/reference/services/navigation/).
+For example, though you could technically implement a GPS as a sensor with just the `GetReadings` method, if you implement it as a movement sensor then you have access to methods like `GetCompassHeading` which allow you to use your GPS module with the [navigation service](/reference/services/navigation/).
 For this reason, it's generally best to choose the API that most closely matches your hardware or software.
 {{< /expand >}}
 
diff --git a/docs/reference/apis/services/base-rc.md b/docs/reference/apis/services/base-rc.md
index 1569076801..11b10bb2ab 100644
--- a/docs/reference/apis/services/base-rc.md
+++ b/docs/reference/apis/services/base-rc.md
@@ -16,7 +16,7 @@ aliases:
 
 The base remote control service API allows you to get a list of inputs from the controller that are being monitored for that control mode.
 
-The [Base remote control service](/operate/reference/services/base-rc/) supports the following methods:
+The [Base remote control service](/reference/services/base-rc/) supports the following methods:
 
 {{< readfile "/static/include/services/apis/generated/base_remote_control-table.md" >}}
 
diff --git a/docs/reference/apis/services/discovery.md b/docs/reference/apis/services/discovery.md
index 842e268429..bb9be1692f 100644
--- a/docs/reference/apis/services/discovery.md
+++ b/docs/reference/apis/services/discovery.md
@@ -12,7 +12,7 @@ aliases:
 ---
 
 The discovery service API allows you to get a list of resources available to configure on a machine based on the hardware that is connected to or part of the machine.
-Discoverable resources can include components that are physically connected to the machine, as well as components that are available on the machine's local network (depending on the implementation of the [discovery service](/operate/reference/services/discovery/)).
+Discoverable resources can include components that are physically connected to the machine, as well as components that are available on the machine's local network (depending on the implementation of the [discovery service](/reference/services/discovery/)).
 
 The discovery service supports the following methods:
 
diff --git a/docs/reference/apis/services/generic.md b/docs/reference/apis/services/generic.md
index 37d1db9afe..d5d254054b 100644
--- a/docs/reference/apis/services/generic.md
+++ b/docs/reference/apis/services/generic.md
@@ -14,7 +14,7 @@ aliases:
 # updated: ""  # When the content was last entirely checked
 ---
 
-The generic service API allows you to give commands to your [generic services](/operate/reference/services/generic/) for running model-specific commands using [`DoCommand`](/reference/apis/services/generic/#docommand).
+The generic service API allows you to give commands to your [generic services](/reference/services/generic/) for running model-specific commands using [`DoCommand`](/reference/apis/services/generic/#docommand).
 
 The generic service supports the following methods:
 
diff --git a/docs/reference/apis/services/navigation.md b/docs/reference/apis/services/navigation.md
index aba86e9603..0e91498f36 100644
--- a/docs/reference/apis/services/navigation.md
+++ b/docs/reference/apis/services/navigation.md
@@ -16,7 +16,7 @@ aliases:
 
 The navigation service API allows you to define waypoints and move your machine along those waypoints while avoiding obstacles.
 
-The [navigation service](/operate/reference/services/navigation/) supports the following methods:
+The [navigation service](/reference/services/navigation/) supports the following methods:
 
 {{< readfile "/static/include/services/apis/generated/navigation-table.md" >}}
 
diff --git a/docs/tutorials/control/gamepad.md b/docs/tutorials/control/gamepad.md
index e378201c3a..0baca0e50a 100644
--- a/docs/tutorials/control/gamepad.md
+++ b/docs/tutorials/control/gamepad.md
@@ -123,7 +123,7 @@ To link the controller input to the base functionality, you need to add the base
 ## Add the base remote control service
 
 Services are software packages that provide robots with higher level functionality.
-To link the controller's input to the base functionality, you need to configure the [base remote control service](/operate/reference/services/base-rc/):
+To link the controller's input to the base functionality, you need to configure the [base remote control service](/reference/services/base-rc/):
 
 {{< tabs >}}
 {{% tab name="Config Builder" %}}
diff --git a/docs/tutorials/services/navigate-with-rover-base.md b/docs/tutorials/services/navigate-with-rover-base.md
index 3899b2345d..c1db1c693b 100644
--- a/docs/tutorials/services/navigate-with-rover-base.md
+++ b/docs/tutorials/services/navigate-with-rover-base.md
@@ -37,7 +37,7 @@ weight: 5
 # SMEs: Ray Bjorkman, Fahmina
 ---
 
-The [navigation service](/operate/reference/services/navigation/) allows you to queue up user-defined waypoints for your machine to move to in the order that you specify.
+The [navigation service](/reference/services/navigation/) allows you to queue up user-defined waypoints for your machine to move to in the order that you specify.
 You can also add obstacles or set linear and angular velocity targets in your navigation service config.
 Viam's motion planner will plan routes that avoid those obstacles and attempt to keep the robot at your specified velocity.
 
@@ -72,7 +72,7 @@ Follow this tutorial to get started using Viam's Navigation service to help your
    3. A [`merged`](/reference/components/movement-sensor/merged/) model aggregating the readings together for the navigation service to consume.
 
    You can use any combo of movement sensors you want as long as you are getting all the types of measurements required.
-   See [the navigation service](/operate/reference/services/navigation/#requirements) for more info on movement sensor requirements.
+   See [the navigation service](/reference/services/navigation/#requirements) for more info on movement sensor requirements.
 
 {{% alert title="Tip" color="tip" %}}
 
@@ -456,7 +456,7 @@ To add the navigation service to your robot, do the following:
    ```
 
    Edit the attributes as applicable.
-   Attribute information is available in [the navigation service documentation](/operate/reference/services/navigation/#configuration).
+   Attribute information is available in [the navigation service documentation](/reference/services/navigation/#configuration).
 
 1. Click **Save** in the top right corner of the screen to save your changes.
 
@@ -464,7 +464,7 @@ Your navigation service should now appear in your machine's **CONFIGURE** tab as
 
 {{<imgproc src="/tutorials/navigate-with-rover-base/navigation-config-builder.png" resize="1200x" declaredimensions=true alt="Navigation Card" style="width:650px" class="shadow imgzoom" >}}
 
-For more detailed information see [the navigation service](/operate/reference/services/navigation/#configuration).
+For more detailed information see [the navigation service](/reference/services/navigation/#configuration).
 
 {{% /tab %}}
 {{% tab name="JSON" %}}
diff --git a/static/include/app/apis/generated/app.md b/static/include/app/apis/generated/app.md
index fddfaaf28a..d3a3a2eba0 100644
--- a/static/include/app/apis/generated/app.md
+++ b/static/include/app/apis/generated/app.md
@@ -2272,7 +2272,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### GetRobotAPIKeys
 
-Gets the [API keys](/operate/control/api-keys/) for the machine.
+Gets the [API keys](/organization/api-keys/) for the machine.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
@@ -3062,7 +3062,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### MarkPartAsMain
 
-Mark a machine part as the [_main_ part](/operate/reference/architecture/parts/#machine-parts) of a machine.
+Mark a machine part as the [_main_ part](/hardware/multi-machine/overview/#machine-parts) of a machine.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
@@ -5903,7 +5903,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### CreateKey
 
-Create a new [API key](/operate/control/api-keys/).
+Create a new [API key](/organization/api-keys/).
 
 {{< tabs >}}
 {{% tab name="Python" %}}
@@ -5980,7 +5980,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### DeleteKey
 
-Delete an [API key](/operate/control/api-keys/).
+Delete an [API key](/organization/api-keys/).
 
 {{< tabs >}}
 {{% tab name="Python" %}}
@@ -6045,7 +6045,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### RotateKey
 
-Rotate an [API key](/operate/control/api-keys/#rotate-an-api-key).
+Rotate an [API key](/organization/api-keys/#rotate-an-api-key).
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/app/apis/overrides/protos/app.CreateKey.md b/static/include/app/apis/overrides/protos/app.CreateKey.md
index 1a995b33fe..9bf3a15a7a 100644
--- a/static/include/app/apis/overrides/protos/app.CreateKey.md
+++ b/static/include/app/apis/overrides/protos/app.CreateKey.md
@@ -1 +1 @@
-Create a new [API key](/operate/control/api-keys/).
+Create a new [API key](/organization/api-keys/).
diff --git a/static/include/app/apis/overrides/protos/app.DeleteKey.md b/static/include/app/apis/overrides/protos/app.DeleteKey.md
index 00e562a4c7..2e659c2697 100644
--- a/static/include/app/apis/overrides/protos/app.DeleteKey.md
+++ b/static/include/app/apis/overrides/protos/app.DeleteKey.md
@@ -1 +1 @@
-Delete an [API key](/operate/control/api-keys/).
+Delete an [API key](/organization/api-keys/).
diff --git a/static/include/app/apis/overrides/protos/app.GetRobotAPIKeys.md b/static/include/app/apis/overrides/protos/app.GetRobotAPIKeys.md
index 66ed6b486e..f4f489a6de 100644
--- a/static/include/app/apis/overrides/protos/app.GetRobotAPIKeys.md
+++ b/static/include/app/apis/overrides/protos/app.GetRobotAPIKeys.md
@@ -1 +1 @@
-Gets the [API keys](/operate/control/api-keys/) for the machine.
+Gets the [API keys](/organization/api-keys/) for the machine.
diff --git a/static/include/app/apis/overrides/protos/app.MarkPartAsMain.md b/static/include/app/apis/overrides/protos/app.MarkPartAsMain.md
index 5a35e66ff4..18259e7817 100644
--- a/static/include/app/apis/overrides/protos/app.MarkPartAsMain.md
+++ b/static/include/app/apis/overrides/protos/app.MarkPartAsMain.md
@@ -1 +1 @@
-Mark a machine part as the [_main_ part](/operate/reference/architecture/parts/#machine-parts) of a machine.
+Mark a machine part as the [_main_ part](/hardware/multi-machine/overview/#machine-parts) of a machine.
diff --git a/static/include/app/apis/overrides/protos/app.RotateKey.md b/static/include/app/apis/overrides/protos/app.RotateKey.md
index f6899fb214..4c53e5784f 100644
--- a/static/include/app/apis/overrides/protos/app.RotateKey.md
+++ b/static/include/app/apis/overrides/protos/app.RotateKey.md
@@ -1 +1 @@
-Rotate an [API key](/operate/control/api-keys/#rotate-an-api-key).
+Rotate an [API key](/organization/api-keys/#rotate-an-api-key).
diff --git a/static/include/applications.md b/static/include/applications.md
index 674a2ebb73..274ce03627 100644
--- a/static/include/applications.md
+++ b/static/include/applications.md
@@ -3,7 +3,7 @@ The `applications` field is an array of application objects with the following p
 <!-- prettier-ignore -->
 | Property     | Type   | Description |
 | ------------ | ------ | ----------- |
-| `name`       | string | The name of your application, which is part of the application's URL (`name_publicnamespace.viamapplications.com`). For more information on valid names see [Valid application identifiers](/operate/modules/advanced/metajson/#valid-application-identifiers). |
+| `name`       | string | The name of your application, which is part of the application's URL (`name_publicnamespace.viamapplications.com`). For more information on valid names see [Valid application identifiers](/build-modules/module-reference/#valid-application-identifiers). |
 | `type` | string | The type of application: `"single_machine"` or `"multi_machine"`. Whether the application can access and operate one machine or multiple machines. |
 | `entrypoint` | string | The path to the HTML entry point for your application. The `entrypoint` field specifies the path to your application's entry point. For example: <ul><li><code>"dist/index.html"</code>: Static content rooted at the `dist` directory</li><li><code>"dist/foo.html"</code>: Static content rooted at the `dist` directory, with `foo.html` as the entry point</li><li><code>"dist/"</code>: Static content rooted at the `dist` directory (assumes `dist/index.html` exists)</li><li><code>"dist/bar/foo.html"</code>: Static content rooted at `dist/bar` with `foo.html` as the entry point</li></ul> |
 | `fragmentIds` | []string | Specify the fragment or fragments that a machine must contain to be selectable from the machine picker screen. Only for single machine applications. |
diff --git a/static/include/components/apis/generated/arm.md b/static/include/components/apis/generated/arm.md
index 0ea4209ebc..5f5f150b47 100644
--- a/static/include/components/apis/generated/arm.md
+++ b/static/include/components/apis/generated/arm.md
@@ -537,7 +537,7 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetKinematics
 
-Get the kinematics information associated with the arm as the format and byte contents of the [kinematics file](/operate/reference/kinematic-chain-config/).
+Get the kinematics information associated with the arm as the format and byte contents of the [kinematics file](/motion-planning/frame-system/overview/).
 
 {{< tabs >}}
 {{% tab name="Python" %}}
@@ -812,8 +812,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the arm in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the arm.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the arm in its current configuration, in the [frame](/reference/services/frame-system/) of the arm.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/audio_in.md b/static/include/components/apis/generated/audio_in.md
index 13fe65d73a..d44c0f69c3 100644
--- a/static/include/components/apis/generated/audio_in.md
+++ b/static/include/components/apis/generated/audio_in.md
@@ -169,8 +169,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the audio in component in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the audio in component.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the audio in component in its current configuration, in the [frame](/reference/services/frame-system/) of the audio in component.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/audio_out.md b/static/include/components/apis/generated/audio_out.md
index 985b5ba377..b0fb935305 100644
--- a/static/include/components/apis/generated/audio_out.md
+++ b/static/include/components/apis/generated/audio_out.md
@@ -170,8 +170,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the audio out component in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the audio out component.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the audio out component in its current configuration, in the [frame](/reference/services/frame-system/) of the audio out component.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/base.md b/static/include/components/apis/generated/base.md
index c55fd9e71c..3862244d16 100644
--- a/static/include/components/apis/generated/base.md
+++ b/static/include/components/apis/generated/base.md
@@ -806,8 +806,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the base in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the base.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the base in its current configuration, in the [frame](/reference/services/frame-system/) of the base.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/board.md b/static/include/components/apis/generated/board.md
index 05e1ff6d4e..f0bc68faac 100644
--- a/static/include/components/apis/generated/board.md
+++ b/static/include/components/apis/generated/board.md
@@ -1367,7 +1367,7 @@ For more information, see the [Python SDK Docs](https://python.viam.dev/autoapi/
 
 **Parameters:**
 
-- `name` [(string)](https://pkg.go.dev/builtin#string): Pin number of the GPIO pin you want to retrieve as a `GPIOPin` interface. Refer to the pinout diagram and data sheet of your [board model](/operate/reference/components/board/#configuration) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
+- `name` [(string)](https://pkg.go.dev/builtin#string): Pin number of the GPIO pin you want to retrieve as a `GPIOPin` interface. Refer to the pinout diagram and data sheet of your [board model](/reference/components/board/#configuration) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
 
 **Returns:**
 
@@ -1390,8 +1390,8 @@ For more information, see the [Go SDK Docs](https://pkg.go.dev/go.viam.com/rdk/c
 
 ### GetGeometries
 
-Get all the geometries associated with the board in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the board.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the board in its current configuration, in the [frame](/reference/services/frame-system/) of the board.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/camera.md b/static/include/components/apis/generated/camera.md
index d2ca68d4fd..a60d9d0147 100644
--- a/static/include/components/apis/generated/camera.md
+++ b/static/include/components/apis/generated/camera.md
@@ -407,8 +407,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the camera in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the camera.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the camera in its current configuration, in the [frame](/reference/services/frame-system/) of the camera.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/encoder.md b/static/include/components/apis/generated/encoder.md
index 5185826ec5..84fbef39ba 100644
--- a/static/include/components/apis/generated/encoder.md
+++ b/static/include/components/apis/generated/encoder.md
@@ -251,8 +251,8 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### GetGeometries
 
-Get all the geometries associated with the encoder in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the encoder.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the encoder in its current configuration, in the [frame](/reference/services/frame-system/) of the encoder.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/gantry.md b/static/include/components/apis/generated/gantry.md
index f016c7f249..d484887a3b 100644
--- a/static/include/components/apis/generated/gantry.md
+++ b/static/include/components/apis/generated/gantry.md
@@ -408,8 +408,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the gantry in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the gantry.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the gantry in its current configuration, in the [frame](/reference/services/frame-system/) of the gantry.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/generic_component.md b/static/include/components/apis/generated/generic_component.md
index 4569d2cb23..f8bff5c681 100644
--- a/static/include/components/apis/generated/generic_component.md
+++ b/static/include/components/apis/generated/generic_component.md
@@ -1,7 +1,7 @@
 ### GetGeometries
 
-Get all the geometries associated with the generic component in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the generic component.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the generic component in its current configuration, in the [frame](/reference/services/frame-system/) of the generic component.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/gripper.md b/static/include/components/apis/generated/gripper.md
index 9739f33585..f51f9529bf 100644
--- a/static/include/components/apis/generated/gripper.md
+++ b/static/include/components/apis/generated/gripper.md
@@ -448,8 +448,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the gripper in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the gripper.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the gripper in its current configuration, in the [frame](/reference/services/frame-system/) of the gripper.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
@@ -670,7 +670,7 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetKinematics
 
-Get the kinematics information associated with the gripper as the format and byte contents of the [kinematics file](/operate/reference/kinematic-chain-config/).
+Get the kinematics information associated with the gripper as the format and byte contents of the [kinematics file](/motion-planning/frame-system/overview/).
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/input_controller.md b/static/include/components/apis/generated/input_controller.md
index 4b22d2e1bb..c7c53551be 100644
--- a/static/include/components/apis/generated/input_controller.md
+++ b/static/include/components/apis/generated/input_controller.md
@@ -236,8 +236,8 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### GetGeometries
 
-Get all the geometries associated with the input controller in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the input controller.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the input controller in its current configuration, in the [frame](/reference/services/frame-system/) of the input controller.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/motor.md b/static/include/components/apis/generated/motor.md
index cb1bb35e68..dcdfc2993e 100644
--- a/static/include/components/apis/generated/motor.md
+++ b/static/include/components/apis/generated/motor.md
@@ -1032,8 +1032,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the motor in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the motor.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the motor in its current configuration, in the [frame](/reference/services/frame-system/) of the motor.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/movement_sensor.md b/static/include/components/apis/generated/movement_sensor.md
index 0fc71eee44..7588942d45 100644
--- a/static/include/components/apis/generated/movement_sensor.md
+++ b/static/include/components/apis/generated/movement_sensor.md
@@ -826,8 +826,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the movement sensor in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the movement sensor.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the movement sensor in its current configuration, in the [frame](/reference/services/frame-system/) of the movement sensor.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/sensor.md b/static/include/components/apis/generated/sensor.md
index 53be45d465..a0ae79ba95 100644
--- a/static/include/components/apis/generated/sensor.md
+++ b/static/include/components/apis/generated/sensor.md
@@ -95,8 +95,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the sensor in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the sensor.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the sensor in its current configuration, in the [frame](/reference/services/frame-system/) of the sensor.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/generated/servo.md b/static/include/components/apis/generated/servo.md
index 8b128393e2..2618844845 100644
--- a/static/include/components/apis/generated/servo.md
+++ b/static/include/components/apis/generated/servo.md
@@ -430,8 +430,8 @@ For more information, see the [Flutter SDK Docs](https://flutter.viam.dev/viam_s
 
 ### GetGeometries
 
-Get all the geometries associated with the servo in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the servo.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the servo in its current configuration, in the [frame](/reference/services/frame-system/) of the servo.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md b/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md
index b987a22412..d9cc04e9c2 100644
--- a/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md
+++ b/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md
@@ -1 +1 @@
-A slice containing the `"name"` of every analog pin [configured](/operate/reference/components/board/#configuration) on the board.
+A slice containing the `"name"` of every analog pin [configured](/reference/components/board/#configuration) on the board.
diff --git a/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md b/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md
index 9e8aef395c..b407c94ae4 100644
--- a/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md
+++ b/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md
@@ -1 +1 @@
-A slice containing the `"name"` of every interrupt [configured](/operate/reference/components/board/#configuration) on the board.
+A slice containing the `"name"` of every interrupt [configured](/reference/components/board/#configuration) on the board.
diff --git a/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md b/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md
index f5322d4d34..b99cf60a44 100644
--- a/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md
+++ b/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md
@@ -1,2 +1,2 @@
 Pin number of the GPIO pin you want to retrieve as a `GPIOPin` interface.
-Refer to the pinout diagram and data sheet of your [board model](/operate/reference/components/board/#configuration) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
+Refer to the pinout diagram and data sheet of your [board model](/reference/components/board/#configuration) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
diff --git a/static/include/components/apis/overrides/protos/arm.GetGeometries.md b/static/include/components/apis/overrides/protos/arm.GetGeometries.md
index 4d7f17a73e..e2f4b11e90 100644
--- a/static/include/components/apis/overrides/protos/arm.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/arm.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the arm in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the arm.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the arm in its current configuration, in the [frame](/reference/services/frame-system/) of the arm.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/arm.GetKinematics.md b/static/include/components/apis/overrides/protos/arm.GetKinematics.md
index 1267d7ad7b..72d7557e3e 100644
--- a/static/include/components/apis/overrides/protos/arm.GetKinematics.md
+++ b/static/include/components/apis/overrides/protos/arm.GetKinematics.md
@@ -1 +1 @@
-Get the kinematics information associated with the arm as the format and byte contents of the [kinematics file](/operate/reference/kinematic-chain-config/).
+Get the kinematics information associated with the arm as the format and byte contents of the [kinematics file](/motion-planning/frame-system/overview/).
diff --git a/static/include/components/apis/overrides/protos/audio_in.GetGeometries.md b/static/include/components/apis/overrides/protos/audio_in.GetGeometries.md
index b00d2a130e..08dfea27fa 100644
--- a/static/include/components/apis/overrides/protos/audio_in.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/audio_in.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the audio in component in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the audio in component.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the audio in component in its current configuration, in the [frame](/reference/services/frame-system/) of the audio in component.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/audio_out.GetGeometries.md b/static/include/components/apis/overrides/protos/audio_out.GetGeometries.md
index 6299348e61..ec569ed83b 100644
--- a/static/include/components/apis/overrides/protos/audio_out.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/audio_out.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the audio out component in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the audio out component.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the audio out component in its current configuration, in the [frame](/reference/services/frame-system/) of the audio out component.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/base.GetGeometries.md b/static/include/components/apis/overrides/protos/base.GetGeometries.md
index cf860ac1e7..a9403a1211 100644
--- a/static/include/components/apis/overrides/protos/base.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/base.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the base in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the base.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the base in its current configuration, in the [frame](/reference/services/frame-system/) of the base.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/board.GetGeometries.md b/static/include/components/apis/overrides/protos/board.GetGeometries.md
index 6b08b5bb17..a2f074fea1 100644
--- a/static/include/components/apis/overrides/protos/board.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/board.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the board in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the board.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the board in its current configuration, in the [frame](/reference/services/frame-system/) of the board.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/button.GetGeometries.md b/static/include/components/apis/overrides/protos/button.GetGeometries.md
index 4d7f17a73e..e2f4b11e90 100644
--- a/static/include/components/apis/overrides/protos/button.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/button.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the arm in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the arm.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the arm in its current configuration, in the [frame](/reference/services/frame-system/) of the arm.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/camera.GetGeometries.md b/static/include/components/apis/overrides/protos/camera.GetGeometries.md
index 0fb4baeda6..a692ed173e 100644
--- a/static/include/components/apis/overrides/protos/camera.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/camera.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the camera in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the camera.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the camera in its current configuration, in the [frame](/reference/services/frame-system/) of the camera.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/encoder.GetGeometries.md b/static/include/components/apis/overrides/protos/encoder.GetGeometries.md
index 5a3dbf489f..1397dbf677 100644
--- a/static/include/components/apis/overrides/protos/encoder.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/encoder.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the encoder in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the encoder.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the encoder in its current configuration, in the [frame](/reference/services/frame-system/) of the encoder.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/gantry.GetGeometries.md b/static/include/components/apis/overrides/protos/gantry.GetGeometries.md
index e8081ab49c..c1755bb276 100644
--- a/static/include/components/apis/overrides/protos/gantry.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/gantry.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the gantry in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the gantry.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the gantry in its current configuration, in the [frame](/reference/services/frame-system/) of the gantry.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/generic_component.GetGeometries.md b/static/include/components/apis/overrides/protos/generic_component.GetGeometries.md
index 3b2c06d113..faf4485064 100644
--- a/static/include/components/apis/overrides/protos/generic_component.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/generic_component.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the generic component in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the generic component.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the generic component in its current configuration, in the [frame](/reference/services/frame-system/) of the generic component.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/gripper.GetGeometries.md b/static/include/components/apis/overrides/protos/gripper.GetGeometries.md
index 52e57b94d8..ada3222a62 100644
--- a/static/include/components/apis/overrides/protos/gripper.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/gripper.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the gripper in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the gripper.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the gripper in its current configuration, in the [frame](/reference/services/frame-system/) of the gripper.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/gripper.GetKinematics.md b/static/include/components/apis/overrides/protos/gripper.GetKinematics.md
index 5981504fe7..a00f0717b3 100644
--- a/static/include/components/apis/overrides/protos/gripper.GetKinematics.md
+++ b/static/include/components/apis/overrides/protos/gripper.GetKinematics.md
@@ -1 +1 @@
-Get the kinematics information associated with the gripper as the format and byte contents of the [kinematics file](/operate/reference/kinematic-chain-config/).
+Get the kinematics information associated with the gripper as the format and byte contents of the [kinematics file](/motion-planning/frame-system/overview/).
diff --git a/static/include/components/apis/overrides/protos/input_controller.GetGeometries.md b/static/include/components/apis/overrides/protos/input_controller.GetGeometries.md
index fddcd5ff80..38358a7d7d 100644
--- a/static/include/components/apis/overrides/protos/input_controller.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/input_controller.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the input controller in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the input controller.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the input controller in its current configuration, in the [frame](/reference/services/frame-system/) of the input controller.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/motor.GetGeometries.md b/static/include/components/apis/overrides/protos/motor.GetGeometries.md
index 452b7df472..72e97773d0 100644
--- a/static/include/components/apis/overrides/protos/motor.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/motor.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the motor in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the motor.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the motor in its current configuration, in the [frame](/reference/services/frame-system/) of the motor.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/movement_sensor.GetGeometries.md b/static/include/components/apis/overrides/protos/movement_sensor.GetGeometries.md
index 0435443b60..0beb8101f7 100644
--- a/static/include/components/apis/overrides/protos/movement_sensor.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/movement_sensor.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the movement sensor in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the movement sensor.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the movement sensor in its current configuration, in the [frame](/reference/services/frame-system/) of the movement sensor.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/power_sensor.GetGeometries.md b/static/include/components/apis/overrides/protos/power_sensor.GetGeometries.md
index e5834b90c9..f15d093b6a 100644
--- a/static/include/components/apis/overrides/protos/power_sensor.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/power_sensor.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the power sensor in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the power sensor.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the power sensor in its current configuration, in the [frame](/reference/services/frame-system/) of the power sensor.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/sensor.GetGeometries.md b/static/include/components/apis/overrides/protos/sensor.GetGeometries.md
index cd81a7e506..21c2cf816f 100644
--- a/static/include/components/apis/overrides/protos/sensor.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/sensor.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the sensor in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the sensor.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the sensor in its current configuration, in the [frame](/reference/services/frame-system/) of the sensor.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/apis/overrides/protos/servo.GetGeometries.md b/static/include/components/apis/overrides/protos/servo.GetGeometries.md
index 52b703a52d..8fa822568a 100644
--- a/static/include/components/apis/overrides/protos/servo.GetGeometries.md
+++ b/static/include/components/apis/overrides/protos/servo.GetGeometries.md
@@ -1,2 +1,2 @@
-Get all the geometries associated with the servo in its current configuration, in the [frame](/operate/reference/services/frame-system/) of the servo.
-The [motion](/operate/reference/services/motion/) and [navigation](/operate/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
+Get all the geometries associated with the servo in its current configuration, in the [frame](/reference/services/frame-system/) of the servo.
+The [motion](/reference/services/motion/) and [navigation](/reference/services/navigation/) services use the relative position of inherent geometries to configured geometries representing obstacles for collision detection and obstacle avoidance while motion planning.
diff --git a/static/include/components/base-sensor.md b/static/include/components/base-sensor.md
index 6e5a50dc90..7ac1738c19 100644
--- a/static/include/components/base-sensor.md
+++ b/static/include/components/base-sensor.md
@@ -1,9 +1,9 @@
 If you want to control your base by specifying a desired velocity in terms of distance/time, for example 5 m/s, and you have a movement sensor that measures the actual velocity, you can use the sensor to adjust the velocity.
-Alternatively, if your base has position reporting motors, you can use the [wheeled odometry](/operate/reference/components/movement-sensor/wheeled-odometry/) movement sensor to get an estimate of the necessary velocities.
+Alternatively, if your base has position reporting motors, you can use the [wheeled odometry](/reference/components/movement-sensor/wheeled-odometry/) movement sensor to get an estimate of the necessary velocities.
 
 Setting the `control_parameters` attribute sets up a PID control loop.
 Setting the `control_parameters` will automatically set up the required PID loop for a sensor controlled base.
-For more information on PID or to set up a more complex control loop, see the [controls package](/operate/reference/controls-package/)
+For more information on PID or to set up a more complex control loop, see the [controls package](/reference/controls-package/)
 
 If you want these values to be auto-tuned, you can set all values to 0: `[ { "type": "linear_velocity", "p": 0, "i": 0, "d": 0 }, { "type": "angular_velocity", "p": 0, "i": 0, "d": 0 } ]`, and `viam-server` will auto-tune and log the calculated values.
 Tuning takes several seconds and spins the motors.
diff --git a/static/include/components/board/board-analogs.md b/static/include/components/board/board-analogs.md
index 6fcda1ec4f..816fbc1dd3 100644
--- a/static/include/components/board/board-analogs.md
+++ b/static/include/components/board/board-analogs.md
@@ -1,6 +1,6 @@
 An [analog-to-digital converter](https://www.electronics-tutorials.ws/combination/analogue-to-digital-converter.html) (ADC) takes a continuous voltage input (analog signal) and converts it to an discrete integer output (digital signal).
 
-ADCs are useful when building a robot, as they enable your board to read the analog signal output by most types of [sensors](/operate/reference/components/sensor/) and other hardware components.
+ADCs are useful when building a robot, as they enable your board to read the analog signal output by most types of [sensors](/reference/components/sensor/) and other hardware components.
 
 To integrate an ADC into your machine, you must first physically connect the pins on your ADC to your board.
 
diff --git a/static/include/components/motor-sensor.md b/static/include/components/motor-sensor.md
index ec1ed4e6d5..aa8158d134 100644
--- a/static/include/components/motor-sensor.md
+++ b/static/include/components/motor-sensor.md
@@ -6,7 +6,7 @@ The first just uses the encoder feedback to increase or decrease the power being
 
 The second requires setting the `control_parameters` attribute, which sets up a PID control loop to adjust the distance and velocity of the motor.
 Setting the `control_parameters` will automatically set up the required PID loop for an encoded motor.
-For more information on PID or to set up a more complex control loop, see the [controls package](/operate/reference/controls-package/)
+For more information on PID or to set up a more complex control loop, see the [controls package](/reference/controls-package/)
 
 If you want these values to be auto-tuned, you can set all values to 0: `{ "p": 0, "i": 0, "d": 0 }`, and `viam-server` will auto-tune and log the calculated values.
 Tuning takes several seconds and spins the motor.
diff --git a/static/include/components/test-control/generic-control.md b/static/include/components/test-control/generic-control.md
index 15eec0016b..e275f5100e 100644
--- a/static/include/components/test-control/generic-control.md
+++ b/static/include/components/test-control/generic-control.md
@@ -5,4 +5,4 @@ Use the card to send arbitrary commands to the resource with [`DoCommand()`](/re
 
 {{<imgproc src="/components/generic/generic-control.png" alt="The generic component in control panel." resize="900x" style="width:500px" class="imgzoom shadow">}}
 
-The example above works for interacting with the generic component model shown in [Deploy control logic](/operate/modules/write-a-logic-module/), but other components require different commands depending on how `DoCommand()` is implemented.
+The example above works for interacting with the generic component model shown in [Deploy control logic](/build-modules/write-a-logic-module/), but other components require different commands depending on how `DoCommand()` is implemented.
diff --git a/static/include/components/test-control/switch-control.md b/static/include/components/test-control/switch-control.md
index 884fc28ea3..69431e5789 100644
--- a/static/include/components/test-control/switch-control.md
+++ b/static/include/components/test-control/switch-control.md
@@ -1,3 +1,3 @@
-Once you have configured your switch, open the switch’s TEST panel on the **CONFIGURE** or [**CONTROL**](/operate/control/web-app/) tab.
+Once you have configured your switch, open the switch’s TEST panel on the **CONFIGURE** or [**CONTROL**](/build-apps/overview/web-app/) tab.
 
 Use the buttons to view and change the switch's position.
diff --git a/static/include/components/troubleshoot/camera.md b/static/include/components/troubleshoot/camera.md
index 8fd75d42bf..f03f4a2072 100644
--- a/static/include/components/troubleshoot/camera.md
+++ b/static/include/components/troubleshoot/camera.md
@@ -10,7 +10,7 @@ If none of these steps work, reach out to us on the [Community Discord](https://
 
 {{% expand "Failed to find the best driver that fits the constraints" %}}
 
-When working with a [camera](/operate/reference/components/camera/) component, depending on the camera, you may need to explicitly provide some camera-specific configuration parameters.
+When working with a [camera](/reference/components/camera/) component, depending on the camera, you may need to explicitly provide some camera-specific configuration parameters.
 
 **Solution:** Check the specifications for your camera, and manually provide configuration parameters such as width and height to the camera component configuration panel.
 On the **CONFIGURE** page, find your camera, then fill in your camera's specific configuration either using the **Show more** button to show the relevant configuration options, or the **JSON** button to enter these attributes manually.
diff --git a/static/include/create-your-own-mr.md b/static/include/create-your-own-mr.md
index 78d2061835..b148c6a535 100644
--- a/static/include/create-your-own-mr.md
+++ b/static/include/create-your-own-mr.md
@@ -1,3 +1,3 @@
 {{< alert title="Add support for other models" color="tip" >}}
-If none of the existing models fit your use case, you can [create a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}}](/operate/modules/write-a-driver-module/) to add support for it.
+If none of the existing models fit your use case, you can [create a {{< glossary_tooltip term_id="modular-resource" text="modular resource" >}}](/build-modules/write-a-driver-module/) to add support for it.
 {{< /alert >}}
diff --git a/static/include/data/capture-supported.md b/static/include/data/capture-supported.md
index f1258cec54..54954b80c3 100644
--- a/static/include/data/capture-supported.md
+++ b/static/include/data/capture-supported.md
@@ -20,12 +20,12 @@
 | [Servo](/hardware/common-components/add-a-servo/)                     | `Position`, `DoCommand` |
 | [Switch](/hardware/common-components/add-a-switch/)                   | `DoCommand` |
 | [Generic](/hardware/common-components/add-a-generic/)                 | `DoCommand` |
-| [Base remote control service](/operate/reference/services/base-rc/) | `DoCommand` |
-| [Discovery service](/operate/reference/services/discovery/)       | `DoCommand` |
+| [Base remote control service](/reference/services/base-rc/) | `DoCommand` |
+| [Discovery service](/reference/services/discovery/)       | `DoCommand` |
 | [Vision service](/vision/configure/)             | `CaptureAllFromCamera`, `DoCommand` |
-| [SLAM service](/operate/reference/services/slam/)                 | `Position`, `PointCloudMap`, `DoCommand` |
-| [Motion service](/operate/reference/services/motion/)             | `DoCommand` |
-| [Navigation service](/operate/reference/services/navigation/)     | `DoCommand` |
+| [SLAM service](/reference/services/slam/)                 | `Position`, `PointCloudMap`, `DoCommand` |
+| [Motion service](/reference/services/motion/)             | `DoCommand` |
+| [Navigation service](/reference/services/navigation/)     | `DoCommand` |
 | Shell service | `DoCommand` |
 
 {{% /tab %}}
diff --git a/static/include/install/install-linux-aarch.md b/static/include/install/install-linux-aarch.md
index 237d8ee432..339c959e11 100644
--- a/static/include/install/install-linux-aarch.md
+++ b/static/include/install/install-linux-aarch.md
@@ -23,4 +23,4 @@ Install `viam-server` on the computer or single-board computer (SBC) that is dir
 1. After you install `viam-server`, a secure connection is automatically established between your machine and Viam.
    When you update your machine's configuration, `viam-server` automatically gets the updates.
 
-   You are ready to [configure supported hardware](/operate/modules/configure-modules/) on your machine.
+   You are ready to [configure supported hardware](/hardware/configure-hardware/) on your machine.
diff --git a/static/include/install/install-linux.md b/static/include/install/install-linux.md
index b74956af6b..b7ec7ac2f8 100644
--- a/static/include/install/install-linux.md
+++ b/static/include/install/install-linux.md
@@ -25,4 +25,4 @@ Install `viam-server` on the computer or single-board computer (SBC) that is dir
 1. After you install `viam-server`, a secure connection is automatically established between your machine and Viam.
    When you update your machine's configuration, `viam-server` automatically gets the updates.
 
-   You are ready to [configure supported hardware](/operate/modules/configure-modules/) on your machine.
+   You are ready to [configure supported hardware](/hardware/configure-hardware/) on your machine.
diff --git a/static/include/install/try-example.md b/static/include/install/try-example.md
index a5459bbbc3..48d8e85167 100644
--- a/static/include/install/try-example.md
+++ b/static/include/install/try-example.md
@@ -15,6 +15,4 @@ Once you've installed `viam-server` and your machine has come online, if your ma
 1. Select a camera and press the Start Game button.
    The goal of the game is to find and show specific objects to the camera.
 
-If you'd like to learn how to create this game, see the [Desk Safari tutorial](/operate/hello-world/tutorial-desk-safari/).
-
 Should the game not work, return to your machine in the Viam web UI and check the **LOGS** tab for errors.
diff --git a/static/include/micro-create-your-own.md b/static/include/micro-create-your-own.md
index 9766cfa41f..0137f005dc 100644
--- a/static/include/micro-create-your-own.md
+++ b/static/include/micro-create-your-own.md
@@ -3,5 +3,5 @@ If none of the existing models fit your use case, you can create a {{< glossary_
 
 The Micro-RDK works differently from the RDK, so creating modular resources for it is different.
 Refer to the [Micro-RDK Module Template on GitHub](https://github.com/viamrobotics/micro-rdk/tree/main/templates/module) for information on how to create custom resources for your microcontroller.
-You will need to [build custom firmware and flash your ESP32 yourself](/operate/modules/advanced/micro-module/) instead of using Viam's prebuilt binary and installer.
+You will need to [build custom firmware and flash your ESP32 yourself](/reference/device-setup/setup-micro/micro-module/) instead of using Viam's prebuilt binary and installer.
 {{< /alert >}}
diff --git a/static/include/micro-rdk-hardware.md b/static/include/micro-rdk-hardware.md
index 068e2c6a53..08ed17b1fb 100644
--- a/static/include/micro-rdk-hardware.md
+++ b/static/include/micro-rdk-hardware.md
@@ -4,7 +4,7 @@ The following ESP32 microcontrollers are supported:
 
 - [ESP32-WROVER Series](https://www.espressif.com/en/products/modules/esp32)
 
-You will also need a data cable to connect the microcontroller to your development machine, though subsequent firmware updates can be made remotely with the [over-the-air (OTA) service](/operate/install/setup-micro/#configure-over-the-air-updates).
+You will also need a data cable to connect the microcontroller to your development machine, though subsequent firmware updates can be made remotely with the [over-the-air (OTA) service](/reference/device-setup/setup-micro/#configure-over-the-air-updates).
 
 Your microcontroller should have at least the following resources available to work with `viam-micro-server`:
 
@@ -12,5 +12,5 @@ Your microcontroller should have at least the following resources available to w
 
 {{< alert title="Tip" color="tip" >}}
 The WROVER allows only a small number of incoming gRPC connections (1-5, depending on resources), whether over HTTP2 or WebRTC.
-You can change this max by [building your own firmware](/operate/install/setup-micro/#build-and-flash-custom-firmware).
+You can change this max by [building your own firmware](/reference/device-setup/setup-micro/#build-and-flash-custom-firmware).
 {{< /alert >}}
diff --git a/static/include/program/authenticate.md b/static/include/program/authenticate.md
index 97cc237729..97ec5584d1 100644
--- a/static/include/program/authenticate.md
+++ b/static/include/program/authenticate.md
@@ -4,7 +4,7 @@ To authenticate yourself to your machine, you need
 
       <!-- we will be releasing the ability to create API keys across all types of resources and combinations soon (i.e an API key can have an authorization on a org, location, machine or any combination of all three). this is correct for now though but it will be changing shortly. -->
 
-   To authenticate, [use a machine part API key](/operate/control/api-keys/) or [an API key](/cli/) with access to the machine.
+   To authenticate, [use a machine part API key](/organization/api-keys/) or [an API key](/cli/) with access to the machine.
    Copy and paste the API key ID and the API key into your environment variables or directly into the code:
 
    {{< tabs >}}
diff --git a/static/include/services/apis/fleet.md b/static/include/services/apis/fleet.md
index 27e46ee887..1a00f273bf 100644
--- a/static/include/services/apis/fleet.md
+++ b/static/include/services/apis/fleet.md
@@ -22,7 +22,7 @@ Method Name | Description
 [`UpdateRobotPart`](/reference/apis/fleet/#updaterobotpart ) | Update the name or configuration of a machine part.
 [`NewRobotPart`](/reference/apis/fleet/#newrobotpart ) | Create a new machine part.
 [`DeleteRobotPart`](/reference/apis/fleet/#deleterobotpart ) | Delete a machine part.
-[`MarkPartAsMain`](/reference/apis/fleet/#markpartasmain ) | Mark a part as the [_main_ part](/operate/reference/architecture/parts/#machine-parts) of a machine.
+[`MarkPartAsMain`](/reference/apis/fleet/#markpartasmain ) | Mark a part as the [_main_ part](/hardware/multi-machine/overview/#machine-parts) of a machine.
 [`MarkPartForRestart`](/reference/apis/fleet/#markpartforrestart ) | Mark a machine part for restart.
 [`CreateRobotPartSecret`](/reference/apis/fleet/#createrobotpartsecret ) | Create a machine part secret. *Deprecated*.
 [`DeleteRobotPartSecret`](/reference/apis/fleet/#deleterobotpartsecret ) | Delete a machine part secret. *Deprecated*.
diff --git a/static/include/services/apis/generated/motion.md b/static/include/services/apis/generated/motion.md
index e4bb4d5954..37f8c17c7d 100644
--- a/static/include/services/apis/generated/motion.md
+++ b/static/include/services/apis/generated/motion.md
@@ -158,7 +158,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### MoveOnMap
 
-Move a [base](/operate/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a SLAM map.
+Move a [base](/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a SLAM map.
 
 `MoveOnMap()` is non blocking, meaning the motion service will move the component to the destination [pose](/motion-planning/reference/orientation-vectors/) after `MoveOnMap()` returns.
 
@@ -172,12 +172,12 @@ You can monitor the progress of the `MoveOnMap()` call by querying `GetPlan()` a
 
 Use the machine's position reported by the SLAM service to check the location of the machine.
 
-`MoveOnMap()` is intended for use with the [navigation service](/operate/reference/services/navigation/), providing autonomous indoor navigation for rover [bases](/operate/reference/components/base/).
+`MoveOnMap()` is intended for use with the [navigation service](/reference/services/navigation/), providing autonomous indoor navigation for rover [bases](/reference/components/base/).
 
 {{< alert title="Requirements" color="info" >}}
-To use `MoveOnMap()`, your [SLAM service](/operate/reference/services/slam/) must implement `GetPointCloudMap()` and `GetPosition()`
+To use `MoveOnMap()`, your SLAM service must implement `GetPointCloudMap()` and `GetPosition()`
 
-Make sure the [SLAM service](/operate/reference/services/slam/) you use alongside this motion service supports the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the SLAM service API:
+Make sure the SLAM service you use alongside this motion service supports the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the SLAM service API:
 
 - It must support `GetPointCloudMap()` to report the SLAM map as a pointcloud.
 - It must support `GetPosition()` to report the machine's current location on the SLAM map.
@@ -190,11 +190,11 @@ Make sure the [SLAM service](/operate/reference/services/slam/) you use alongsid
 
 - `component_name` ([str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str)) (required): The `ResourceName` of the base to move.
 - `destination` ([viam.proto.common.Pose](https://python.viam.dev/autoapi/viam/components/arm/index.html#viam.components.arm.Pose)) (required): The destination, which can be any [Pose](https://python.viam.dev/autoapi/viam/proto/common/index.html#viam.proto.common.Pose) with respect to the SLAM map's origin.
-- `slam_service_name` ([str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str)) (required): The `ResourceName` of the [SLAM service](/operate/reference/services/slam/) from which the SLAM map is requested.
+- `slam_service_name` ([str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str)) (required): The `ResourceName` of the SLAM service from which the SLAM map is requested.
 - `configuration` ([viam.proto.service.motion.MotionConfiguration](https://python.viam.dev/autoapi/viam/gen/service/motion/v1/motion_pb2/index.html#viam.gen.service.motion.v1.motion_pb2.MotionConfiguration)) (optional): 
 The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
 
-- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
 - `position_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the position of the machine.
 - `obstacle_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the vision service for new obstacles.
 - `plan_deviation_m` [(float)](https://docs.python.org/3/library/functions.html#float): The distance in meters that the machine can deviate from the motion plan. By default this is set to 2.6 m which is an appropriate value for outdoor usage. When you use the `MoveOnMap()` method from the **CONTROL** tab, the default is overwritten to 0.5 m for testing.
@@ -240,9 +240,9 @@ A `MoveOnMapReq` which contains the following values:
 
 - `ComponentName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the base to move.
 - `Destination` [(spatialmath.Pose)](https://pkg.go.dev/go.viam.com/rdk/spatialmath#Pose): The destination, which can be any [Pose](https://python.viam.dev/autoapi/viam/proto/common/index.html#viam.proto.common.Pose) with respect to the SLAM map's origin.
-- `SlamName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the [SLAM service](/operate/reference/services/slam/) from which the SLAM map is requested.
+- `SlamName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the SLAM service from which the SLAM map is requested.
 - `MotionConfig` [(\*MotionConfiguration)](https://pkg.go.dev/go.viam.com/rdk/services/motion#MotionConfiguration): The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
-  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
   - `PositionPollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the position of the machine.
   - `ObstaclePollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the vision service for new obstacles.
   - `PlanDeviationM` [(float64)](https://pkg.go.dev/builtin#float64): The distance in meters that the machine can deviate from the motion plan. By default this is set to 2.6 m which is an appropriate value for outdoor usage. When you use the **CONTROL** tab, the underlying calls to `MoveOnMap()` use 0.5 m instead.
@@ -341,8 +341,8 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### MoveOnGlobe
 
-Move a [base](/operate/reference/components/base/) component to a destination GPS point, represented in geographic notation _(latitude, longitude)_.
-Use a [movement sensor](/operate/reference/components/movement-sensor/) to check the location of the machine.
+Move a [base](/reference/components/base/) component to a destination GPS point, represented in geographic notation _(latitude, longitude)_.
+Use a [movement sensor](/reference/components/movement-sensor/) to check the location of the machine.
 
 `MoveOnGlobe()` is non blocking, meaning the motion service will move the component to the destination GPS point after `MoveOnGlobe()` returns.
 
@@ -354,12 +354,12 @@ If you specify a goal pose and the robot's current position is already within th
 
 You can monitor the progress of the `MoveOnGlobe()` call by querying `GetPlan()` and `ListPlanStatuses()`.
 
-`MoveOnGlobe()` is intended for use with the [navigation service](/operate/reference/services/navigation/), providing autonomous GPS navigation for rover [bases](/operate/reference/components/base/).
+`MoveOnGlobe()` is intended for use with the [navigation service](/reference/services/navigation/), providing autonomous GPS navigation for rover [bases](/reference/components/base/).
 
 {{< alert title="Requirements" color="info" >}}
 To use `MoveOnGlobe()`, your movement sensor must be able to measure the GPS location and orientation of the machine.
 
-Make sure the [movement sensor](/operate/reference/components/movement-sensor/) you use supports usage of the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the [movement sensor API](/reference/apis/components/movement-sensor/).
+Make sure the [movement sensor](/reference/components/movement-sensor/) you use supports usage of the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the [movement sensor API](/reference/apis/components/movement-sensor/).
 
 - It must support `GetPosition()` to report the machine's current GPS location.
 - It must **also** support **either** `GetCompassHeading()` or `GetOrientation()` to report which way the machine is facing.
@@ -372,7 +372,7 @@ The `heading` parameter is experimental.
 Specifying `heading` in a request to `MoveOnGlobe` is not currently recommended if the minimum turning radius of your component is greater than zero, as this combination may cause high latency in the [motion planning algorithms](/reference/services/motion/algorithms/).
 
 Specifying `obstacles` in a request to `MoveOnGlobe()` will cause an error if you configure a `"translation"` in the `"geometries"` of any of the `GeoGeometry` objects.
-Translation in obstacles is not supported by the [navigation service](/operate/reference/services/navigation/).
+Translation in obstacles is not supported by the [navigation service](/reference/services/navigation/).
 
 {{< /alert >}}
 
@@ -383,13 +383,13 @@ Translation in obstacles is not supported by the [navigation service](/operate/r
 
 - `component_name` ([str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str)) (required): The `ResourceName` of the base to move.
 - `destination` ([viam.proto.common.GeoPoint](https://python.viam.dev/autoapi/viam/components/movement_sensor/index.html#viam.components.movement_sensor.GeoPoint)) (required): The location of the component's destination, represented in geographic notation as a [GeoPoint](https://python.viam.dev/autoapi/viam/components/movement_sensor/index.html#viam.components.movement_sensor.GeoPoint) _(lat, lng)_.
-- `movement_sensor_name` ([str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str)) (required): The `ResourceName` of the [movement sensor](/operate/reference/components/movement-sensor/) that you want to use to check the machine's location.
+- `movement_sensor_name` ([str](https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str)) (required): The `ResourceName` of the [movement sensor](/reference/components/movement-sensor/) that you want to use to check the machine's location.
 - `obstacles` ([Sequence[viam.proto.common.GeoGeometry]](https://python.viam.dev/autoapi/viam/gen/common/v1/common_pb2/index.html#viam.gen.common.v1.common_pb2.GeoGeometry)) (optional): Obstacles to consider when planning the motion of the component, with each represented as a `GeoGeometry`. <ul><li> Default: `None` </li></ul>
 - `heading` ([float](https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex)) (optional): The compass heading, in degrees, that the machine's movement sensor should report at the `destination` point. <ul><li> Range: `[0-360)` `0`: North, `90`: East, `180`: South, `270`: West </li><li>Default: `None`</li></ul>
 - `configuration` ([viam.proto.service.motion.MotionConfiguration](https://python.viam.dev/autoapi/viam/gen/service/motion/v1/motion_pb2/index.html#viam.gen.service.motion.v1.motion_pb2.MotionConfiguration)) (optional): 
 The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
 
-- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
 - `position_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the position of the machine.
 - `obstacle_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the vision service for new obstacles.
 - `plan_deviation_m` [(float)](https://docs.python.org/3/library/functions.html#float): The distance in meters that the machine can deviate from the motion plan.
@@ -435,10 +435,10 @@ A `MoveOnGlobeReq` which contains the following values:
 - `componentName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the base to move.
 - `destination` [(\*geo.Point)](https://pkg.go.dev/github.com/kellydunn/golang-geo#Point): The location of the component's destination, represented in geographic notation as a [Point](https://pkg.go.dev/github.com/kellydunn/golang-geo#Point) _(lat, lng)_.
 - `heading` [(float64)](https://pkg.go.dev/builtin#float64): The compass heading, in degrees, that the machine's movement sensor should report at the `destination` point. <ul><li> Range: `[0-360)` 0: North, 90: East, 180: South, 270: West</li><li>Default: `0`</li></ul>
-- `movementSensorName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the [movement sensor](/operate/reference/components/movement-sensor/) that you want to use to check the machine's location.
+- `movementSensorName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the [movement sensor](/reference/components/movement-sensor/) that you want to use to check the machine's location.
 - `obstacles` [([]\*spatialmath.GeoGeometry)](https://pkg.go.dev/go.viam.com/rdk/spatialmath#GeoGeometry): Obstacles to consider when planning the motion of the component, with each represented as a `GeoGeometry`. <ul><li> Default: `nil` </li></ul>
 - `motionConfig` [(\*MotionConfiguration)](https://pkg.go.dev/go.viam.com/rdk/services/motion#MotionConfiguration): The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
-  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
   - `PositionPollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the position of the machine.
   - `ObstaclePollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the vision service for new obstacles.
   - `PlanDeviationM` [(float64)](https://pkg.go.dev/builtin#float64): The distance in meters that the machine can deviate from the motion plan.
@@ -580,7 +580,7 @@ gripperPoseInWorld = await motion.get_pose(component_name="my_gripper",
                                            destination_frame="world")
 ```
 
-The following code example gets the pose of the tip of a [gripper](/operate/reference/components/gripper/) named `my_gripper` which is attached to the end of an arm, in the "world" `reference_frame`:
+The following code example gets the pose of the tip of a [gripper](/reference/components/gripper/) named `my_gripper` which is attached to the end of an arm, in the "world" `reference_frame`:
 
 ```python {class="line-numbers linkable-line-numbers"}
 from viam.components.gripper import Gripper
@@ -666,7 +666,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### StopPlan
 
-Stop a [base](/operate/reference/components/base/) component being moved by an in progress [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call.
+Stop a [base](/reference/components/base/) component being moved by an in progress [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
@@ -844,7 +844,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### GetPlan
 
-By default, returns the plan history of the most recent [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call to move a [base](/operate/reference/components/base/) component.
+By default, returns the plan history of the most recent [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call to move a [base](/reference/components/base/) component.
 
 The plan history for executions before the most recent can be requested by providing an `ExecutionID` in the request.
 
diff --git a/static/include/services/apis/generated/navigation.md b/static/include/services/apis/generated/navigation.md
index 8f6001e799..9bff89b9b0 100644
--- a/static/include/services/apis/generated/navigation.md
+++ b/static/include/services/apis/generated/navigation.md
@@ -485,7 +485,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 Get an array or list of the obstacles currently in the service's data storage.
 These are objects designated for the robot to avoid when navigating.
 These include all transient obstacles which are discovered by the vision services configured for the navigation service, in addition to the obstacles that are configured as a part of the service.
-See the [motion service](/operate/reference/services/motion/) for more information.
+See the [motion service](/reference/services/motion/) for more information.
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/services/apis/generated/slam.md b/static/include/services/apis/generated/slam.md
index 2c1c87bd61..827c64431d 100644
--- a/static/include/services/apis/generated/slam.md
+++ b/static/include/services/apis/generated/slam.md
@@ -248,7 +248,7 @@ An object containing four fields:
 
 - `SensorInfo` [(SensorInfo[])](https://pkg.go.dev/go.viam.com/api/service/slam/v1#SensorInfo): Information about the sensors (camera and movement sensor) configured for your SLAM service, including the name and type of sensor.
 - `CloudSlam` [(bool)](https://pkg.go.dev/builtin#bool): A boolean which indicates whether the session is being run in the cloud.
-- `MappingMode` [(MappingMode)](https://pkg.go.dev/go.viam.com/rdk/services/slam#MappingMode): Represents the [form of mapping and localizing the current session is performing](/operate/reference/services/slam/cartographer/#using-cartographer). This includes creating a new map, localizing on an existing map and updating an existing map.
+- `MappingMode` [(MappingMode)](https://pkg.go.dev/go.viam.com/rdk/services/slam#MappingMode): Represents the [form of mapping and localizing the current session is performing](/reference/services/slam/cartographer/#using-cartographer). This includes creating a new map, localizing on an existing map and updating an existing map.
 - `InternalStateFileType` [(string)](https://pkg.go.dev/builtin#string): The file type the service's internal state algorithm is stored in.
 - [(error)](https://pkg.go.dev/builtin#error): An error, if one occurred.
 
diff --git a/static/include/services/apis/overrides/methods/go.motion.Move.constraints.md b/static/include/services/apis/overrides/methods/go.motion.Move.constraints.md
index 3ab0e93692..47e6b600ec 100644
--- a/static/include/services/apis/overrides/methods/go.motion.Move.constraints.md
+++ b/static/include/services/apis/overrides/methods/go.motion.Move.constraints.md
@@ -1,2 +1,2 @@
-Pass in optional [motion constraints](/operate/reference/services/motion/constraints/).
+Pass in optional [motion constraints](/reference/services/motion/constraints/).
 By default, motion is unconstrained with the exception of obstacle avoidance.
diff --git a/static/include/services/apis/overrides/methods/go.motion.Move.destination.md b/static/include/services/apis/overrides/methods/go.motion.Move.destination.md
index 03f2b7e998..f3c30b4222 100644
--- a/static/include/services/apis/overrides/methods/go.motion.Move.destination.md
+++ b/static/include/services/apis/overrides/methods/go.motion.Move.destination.md
@@ -1,4 +1,4 @@
 Describes where the `component_name` should end up.
-Can be any pose, from the perspective of any component whose location is configured as a [`frame`](/operate/reference/services/frame-system/).
+Can be any pose, from the perspective of any component whose location is configured as a [`frame`](/reference/services/frame-system/).
 Note that the destination pose is relative to the distal end of the specified frame.
 This means that if the `destination` is the same as the `component_name` frame, for example an arm's frame, then a pose of `{X: 10, Y: 0, Z: 0}` will move that arm’s end effector by 10 mm in the local `X` direction.
diff --git a/static/include/services/apis/overrides/methods/go.motion.MoveOnGlobe.req.md b/static/include/services/apis/overrides/methods/go.motion.MoveOnGlobe.req.md
index dd430435cd..12d8d49856 100644
--- a/static/include/services/apis/overrides/methods/go.motion.MoveOnGlobe.req.md
+++ b/static/include/services/apis/overrides/methods/go.motion.MoveOnGlobe.req.md
@@ -5,10 +5,10 @@ A `MoveOnGlobeReq` which contains the following values:
 - `componentName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the base to move.
 - `destination` [(\*geo.Point)](https://pkg.go.dev/github.com/kellydunn/golang-geo#Point): The location of the component's destination, represented in geographic notation as a [Point](https://pkg.go.dev/github.com/kellydunn/golang-geo#Point) _(lat, lng)_.
 - `heading` [(float64)](https://pkg.go.dev/builtin#float64): The compass heading, in degrees, that the machine's movement sensor should report at the `destination` point. <ul><li> Range: `[0-360)` 0: North, 90: East, 180: South, 270: West</li><li>Default: `0`</li></ul>
-- `movementSensorName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the [movement sensor](/operate/reference/components/movement-sensor/) that you want to use to check the machine's location.
+- `movementSensorName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the [movement sensor](/reference/components/movement-sensor/) that you want to use to check the machine's location.
 - `obstacles` [([]\*spatialmath.GeoGeometry)](https://pkg.go.dev/go.viam.com/rdk/spatialmath#GeoGeometry): Obstacles to consider when planning the motion of the component, with each represented as a `GeoGeometry`. <ul><li> Default: `nil` </li></ul>
 - `motionConfig` [(\*MotionConfiguration)](https://pkg.go.dev/go.viam.com/rdk/services/motion#MotionConfiguration): The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
-  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
   - `PositionPollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the position of the machine.
   - `ObstaclePollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the vision service for new obstacles.
   - `PlanDeviationM` [(float64)](https://pkg.go.dev/builtin#float64): The distance in meters that the machine can deviate from the motion plan.
diff --git a/static/include/services/apis/overrides/methods/go.motion.MoveOnMap.req.md b/static/include/services/apis/overrides/methods/go.motion.MoveOnMap.req.md
index 3942aabe81..8b6fcfb4e9 100644
--- a/static/include/services/apis/overrides/methods/go.motion.MoveOnMap.req.md
+++ b/static/include/services/apis/overrides/methods/go.motion.MoveOnMap.req.md
@@ -4,9 +4,9 @@ A `MoveOnMapReq` which contains the following values:
 
 - `ComponentName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the base to move.
 - `Destination` [(spatialmath.Pose)](https://pkg.go.dev/go.viam.com/rdk/spatialmath#Pose): The destination, which can be any [Pose](https://python.viam.dev/autoapi/viam/proto/common/index.html#viam.proto.common.Pose) with respect to the SLAM map's origin.
-- `SlamName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the [SLAM service](/operate/reference/services/slam/) from which the SLAM map is requested.
+- `SlamName` [(resource.Name)](https://pkg.go.dev/go.viam.com/rdk/resource#Name): The `resource.Name` of the SLAM service from which the SLAM map is requested.
 - `MotionConfig` [(\*MotionConfiguration)](https://pkg.go.dev/go.viam.com/rdk/services/motion#MotionConfiguration): The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
-  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+  - `ObstacleDetectors` [([]ObstacleDetectorName)](https://pkg.go.dev/go.viam.com/rdk/services/motion#ObstacleDetectorName): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
   - `PositionPollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the position of the machine.
   - `ObstaclePollingFreqHz` [(float64)](https://pkg.go.dev/builtin#float64): The frequency in hz to poll the vision service for new obstacles.
   - `PlanDeviationM` [(float64)](https://pkg.go.dev/builtin#float64): The distance in meters that the machine can deviate from the motion plan. By default this is set to 2.6 m which is an appropriate value for outdoor usage. When you use the **CONTROL** tab, the underlying calls to `MoveOnMap()` use 0.5 m instead.
diff --git a/static/include/services/apis/overrides/methods/go.slam.Properties.Properties.return.md b/static/include/services/apis/overrides/methods/go.slam.Properties.Properties.return.md
index a53a72dc77..bf89d44e20 100644
--- a/static/include/services/apis/overrides/methods/go.slam.Properties.Properties.return.md
+++ b/static/include/services/apis/overrides/methods/go.slam.Properties.Properties.return.md
@@ -5,5 +5,5 @@ An object containing four fields:
 
 - `SensorInfo` [(SensorInfo[])](https://pkg.go.dev/go.viam.com/api/service/slam/v1#SensorInfo): Information about the sensors (camera and movement sensor) configured for your SLAM service, including the name and type of sensor.
 - `CloudSlam` [(bool)](https://pkg.go.dev/builtin#bool): A boolean which indicates whether the session is being run in the cloud.
-- `MappingMode` [(MappingMode)](https://pkg.go.dev/go.viam.com/rdk/services/slam#MappingMode): Represents the [form of mapping and localizing the current session is performing](/operate/reference/services/slam/cartographer/#using-cartographer). This includes creating a new map, localizing on an existing map and updating an existing map.
+- `MappingMode` [(MappingMode)](https://pkg.go.dev/go.viam.com/rdk/services/slam#MappingMode): Represents the [form of mapping and localizing the current session is performing](/reference/services/slam/cartographer/#using-cartographer). This includes creating a new map, localizing on an existing map and updating an existing map.
 - `InternalStateFileType` [(string)](https://pkg.go.dev/builtin#string): The file type the service's internal state algorithm is stored in.
diff --git a/static/include/services/apis/overrides/methods/python.motion.get_pose.after.md b/static/include/services/apis/overrides/methods/python.motion.get_pose.after.md
index 457236be12..b55a93411c 100644
--- a/static/include/services/apis/overrides/methods/python.motion.get_pose.after.md
+++ b/static/include/services/apis/overrides/methods/python.motion.get_pose.after.md
@@ -1,4 +1,4 @@
-The following code example gets the pose of the tip of a [gripper](/operate/reference/components/gripper/) named `my_gripper` which is attached to the end of an arm, in the "world" `reference_frame`:
+The following code example gets the pose of the tip of a [gripper](/reference/components/gripper/) named `my_gripper` which is attached to the end of an arm, in the "world" `reference_frame`:
 
 ```python {class="line-numbers linkable-line-numbers"}
 from viam.components.gripper import Gripper
diff --git a/static/include/services/apis/overrides/methods/python.motion.move.constraints.md b/static/include/services/apis/overrides/methods/python.motion.move.constraints.md
index 6dc85ebe2c..66ed90c8bb 100644
--- a/static/include/services/apis/overrides/methods/python.motion.move.constraints.md
+++ b/static/include/services/apis/overrides/methods/python.motion.move.constraints.md
@@ -1,2 +1,2 @@
-Pass in [motion constraints](/operate/reference/services/motion/constraints/).
+Pass in [motion constraints](/reference/services/motion/constraints/).
 By default, motion is unconstrained with the exception of obstacle avoidance.
diff --git a/static/include/services/apis/overrides/methods/python.motion.move.destination.md b/static/include/services/apis/overrides/methods/python.motion.move.destination.md
index f407b2077f..950690f495 100644
--- a/static/include/services/apis/overrides/methods/python.motion.move.destination.md
+++ b/static/include/services/apis/overrides/methods/python.motion.move.destination.md
@@ -1,2 +1,2 @@
 Describes where the `component_name` frame should be moved to.
-Can be any pose, from the perspective of any component whose location is configured as a [`frame`](/operate/reference/services/frame-system/).
+Can be any pose, from the perspective of any component whose location is configured as a [`frame`](/reference/services/frame-system/).
diff --git a/static/include/services/apis/overrides/methods/python.motion.move_on_globe.configuration.md b/static/include/services/apis/overrides/methods/python.motion.move_on_globe.configuration.md
index 060f526520..cd60520bdb 100644
--- a/static/include/services/apis/overrides/methods/python.motion.move_on_globe.configuration.md
+++ b/static/include/services/apis/overrides/methods/python.motion.move_on_globe.configuration.md
@@ -2,7 +2,7 @@
 
 The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
 
-- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
 - `position_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the position of the machine.
 - `obstacle_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the vision service for new obstacles.
 - `plan_deviation_m` [(float)](https://docs.python.org/3/library/functions.html#float): The distance in meters that the machine can deviate from the motion plan.
diff --git a/static/include/services/apis/overrides/methods/python.motion.move_on_globe.movement_sensor_name.md b/static/include/services/apis/overrides/methods/python.motion.move_on_globe.movement_sensor_name.md
index b7bd380183..e4281662f8 100644
--- a/static/include/services/apis/overrides/methods/python.motion.move_on_globe.movement_sensor_name.md
+++ b/static/include/services/apis/overrides/methods/python.motion.move_on_globe.movement_sensor_name.md
@@ -1 +1 @@
-The `ResourceName` of the [movement sensor](/operate/reference/components/movement-sensor/) that you want to use to check the machine's location.
+The `ResourceName` of the [movement sensor](/reference/components/movement-sensor/) that you want to use to check the machine's location.
diff --git a/static/include/services/apis/overrides/methods/python.motion.move_on_map.configuration.md b/static/include/services/apis/overrides/methods/python.motion.move_on_map.configuration.md
index 7f5ce3f7ce..7387587791 100644
--- a/static/include/services/apis/overrides/methods/python.motion.move_on_map.configuration.md
+++ b/static/include/services/apis/overrides/methods/python.motion.move_on_map.configuration.md
@@ -2,7 +2,7 @@
 
 The configuration you want to set across this machine for this motion service. This parameter and each of its fields are optional.
 
-- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/operate/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
+- `obstacle_detectors` [(Iterable[ObstacleDetector])](https://python.viam.dev/autoapi/viam/proto/service/motion/index.html#viam.proto.service.motion.ObstacleDetector): The names of each [vision service](/reference/services/vision/) and [camera](/reference/components/camera/) resource pair you want to use for transient obstacle avoidance.
 - `position_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the position of the machine.
 - `obstacle_polling_frequency_hz` [(float)](https://docs.python.org/3/library/functions.html#float): The frequency in hz to poll the vision service for new obstacles.
 - `plan_deviation_m` [(float)](https://docs.python.org/3/library/functions.html#float): The distance in meters that the machine can deviate from the motion plan. By default this is set to 2.6 m which is an appropriate value for outdoor usage. When you use the `MoveOnMap()` method from the **CONTROL** tab, the default is overwritten to 0.5 m for testing.
diff --git a/static/include/services/apis/overrides/methods/python.motion.move_on_map.slam_service_name.md b/static/include/services/apis/overrides/methods/python.motion.move_on_map.slam_service_name.md
index e4dafa9e13..3467cc9ad3 100644
--- a/static/include/services/apis/overrides/methods/python.motion.move_on_map.slam_service_name.md
+++ b/static/include/services/apis/overrides/methods/python.motion.move_on_map.slam_service_name.md
@@ -1 +1 @@
-The `ResourceName` of the [SLAM service](/operate/reference/services/slam/) from which the SLAM map is requested.
+The `ResourceName` of the SLAM service from which the SLAM map is requested.
diff --git a/static/include/services/apis/overrides/protos/motion.GetPlan.md b/static/include/services/apis/overrides/protos/motion.GetPlan.md
index 13f1e9cfa3..9334713e7f 100644
--- a/static/include/services/apis/overrides/protos/motion.GetPlan.md
+++ b/static/include/services/apis/overrides/protos/motion.GetPlan.md
@@ -1,4 +1,4 @@
-By default, returns the plan history of the most recent [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call to move a [base](/operate/reference/components/base/) component.
+By default, returns the plan history of the most recent [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call to move a [base](/reference/components/base/) component.
 
 The plan history for executions before the most recent can be requested by providing an `ExecutionID` in the request.
 
diff --git a/static/include/services/apis/overrides/protos/motion.GetPose.md b/static/include/services/apis/overrides/protos/motion.GetPose.md
index 085f69ca1b..e3706676fc 100644
--- a/static/include/services/apis/overrides/protos/motion.GetPose.md
+++ b/static/include/services/apis/overrides/protos/motion.GetPose.md
@@ -1,3 +1,3 @@
-`GetPose` gets the location and orientation of a component within the [frame system](/operate/reference/services/frame-system/).
+`GetPose` gets the location and orientation of a component within the [frame system](/reference/services/frame-system/).
 The return type of this function is a `PoseInFrame` describing the pose of the specified component with respect to the specified destination frame.
 You can use the `supplemental_transforms` argument to augment the machine's existing frame system with supplemental frames.
diff --git a/static/include/services/apis/overrides/protos/motion.MoveOnGlobe.md b/static/include/services/apis/overrides/protos/motion.MoveOnGlobe.md
index 8d4d765145..32c93e2771 100644
--- a/static/include/services/apis/overrides/protos/motion.MoveOnGlobe.md
+++ b/static/include/services/apis/overrides/protos/motion.MoveOnGlobe.md
@@ -1,5 +1,5 @@
-Move a [base](/operate/reference/components/base/) component to a destination GPS point, represented in geographic notation _(latitude, longitude)_.
-Use a [movement sensor](/operate/reference/components/movement-sensor/) to check the location of the machine.
+Move a [base](/reference/components/base/) component to a destination GPS point, represented in geographic notation _(latitude, longitude)_.
+Use a [movement sensor](/reference/components/movement-sensor/) to check the location of the machine.
 
 `MoveOnGlobe()` is non blocking, meaning the motion service will move the component to the destination GPS point after `MoveOnGlobe()` returns.
 
@@ -11,12 +11,12 @@ If you specify a goal pose and the robot's current position is already within th
 
 You can monitor the progress of the `MoveOnGlobe()` call by querying `GetPlan()` and `ListPlanStatuses()`.
 
-`MoveOnGlobe()` is intended for use with the [navigation service](/operate/reference/services/navigation/), providing autonomous GPS navigation for rover [bases](/operate/reference/components/base/).
+`MoveOnGlobe()` is intended for use with the [navigation service](/reference/services/navigation/), providing autonomous GPS navigation for rover [bases](/reference/components/base/).
 
 {{< alert title="Requirements" color="info" >}}
 To use `MoveOnGlobe()`, your movement sensor must be able to measure the GPS location and orientation of the machine.
 
-Make sure the [movement sensor](/operate/reference/components/movement-sensor/) you use supports usage of the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the [movement sensor API](/reference/apis/components/movement-sensor/).
+Make sure the [movement sensor](/reference/components/movement-sensor/) you use supports usage of the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the [movement sensor API](/reference/apis/components/movement-sensor/).
 
 - It must support `GetPosition()` to report the machine's current GPS location.
 - It must **also** support **either** `GetCompassHeading()` or `GetOrientation()` to report which way the machine is facing.
@@ -26,9 +26,9 @@ Make sure the [movement sensor](/operate/reference/components/movement-sensor/)
 {{< alert title="Stability Notice" color="alert" >}}
 
 The `heading` parameter is experimental.
-Specifying `heading` in a request to `MoveOnGlobe` is not currently recommended if the minimum turning radius of your component is greater than zero, as this combination may cause high latency in the [motion planning algorithms](/operate/reference/services/motion/algorithms/).
+Specifying `heading` in a request to `MoveOnGlobe` is not currently recommended if the minimum turning radius of your component is greater than zero, as this combination may cause high latency in the [motion planning algorithms](/reference/services/motion/algorithms/).
 
 Specifying `obstacles` in a request to `MoveOnGlobe()` will cause an error if you configure a `"translation"` in the `"geometries"` of any of the `GeoGeometry` objects.
-Translation in obstacles is not supported by the [navigation service](/operate/reference/services/navigation/).
+Translation in obstacles is not supported by the [navigation service](/reference/services/navigation/).
 
 {{< /alert >}}
diff --git a/static/include/services/apis/overrides/protos/motion.MoveOnMap.md b/static/include/services/apis/overrides/protos/motion.MoveOnMap.md
index d60847e4cd..87b8089d1d 100644
--- a/static/include/services/apis/overrides/protos/motion.MoveOnMap.md
+++ b/static/include/services/apis/overrides/protos/motion.MoveOnMap.md
@@ -1,4 +1,4 @@
-Move a [base](/operate/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a SLAM map.
+Move a [base](/reference/components/base/) component to a destination [pose](/motion-planning/reference/orientation-vectors/) on a SLAM map.
 
 `MoveOnMap()` is non blocking, meaning the motion service will move the component to the destination [pose](/motion-planning/reference/orientation-vectors/) after `MoveOnMap()` returns.
 
@@ -12,12 +12,12 @@ You can monitor the progress of the `MoveOnMap()` call by querying `GetPlan()` a
 
 Use the machine's position reported by the SLAM service to check the location of the machine.
 
-`MoveOnMap()` is intended for use with the [navigation service](/operate/reference/services/navigation/), providing autonomous indoor navigation for rover [bases](/operate/reference/components/base/).
+`MoveOnMap()` is intended for use with the [navigation service](/reference/services/navigation/), providing autonomous indoor navigation for rover [bases](/reference/components/base/).
 
 {{< alert title="Requirements" color="info" >}}
-To use `MoveOnMap()`, your [SLAM service](/operate/reference/services/slam/) must implement `GetPointCloudMap()` and `GetPosition()`
+To use `MoveOnMap()`, your SLAM service must implement `GetPointCloudMap()` and `GetPosition()`
 
-Make sure the [SLAM service](/operate/reference/services/slam/) you use alongside this motion service supports the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the [SLAM service API](/reference/apis/services/slam/):
+Make sure the SLAM service you use alongside this motion service supports the following methods in its {{< glossary_tooltip term_id="model" text="model's" >}} implementation of the SLAM service API:
 
 - It must support `GetPointCloudMap()` to report the SLAM map as a pointcloud.
 - It must support `GetPosition()` to report the machine's current location on the SLAM map.
diff --git a/static/include/services/apis/overrides/protos/motion.StopPlan.md b/static/include/services/apis/overrides/protos/motion.StopPlan.md
index c826dd78f3..c736e92cda 100644
--- a/static/include/services/apis/overrides/protos/motion.StopPlan.md
+++ b/static/include/services/apis/overrides/protos/motion.StopPlan.md
@@ -1 +1 @@
-Stop a [base](/operate/reference/components/base/) component being moved by an in progress [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call.
+Stop a [base](/reference/components/base/) component being moved by an in progress [`MoveOnGlobe`](/reference/apis/services/motion/#moveonglobe) or [`MoveOnMap`](/reference/apis/services/motion/#moveonmap) call.
diff --git a/static/include/services/apis/overrides/protos/navigation.GetObstacles.md b/static/include/services/apis/overrides/protos/navigation.GetObstacles.md
index 1a21180b2b..764b0382fa 100644
--- a/static/include/services/apis/overrides/protos/navigation.GetObstacles.md
+++ b/static/include/services/apis/overrides/protos/navigation.GetObstacles.md
@@ -1,4 +1,4 @@
 Get an array or list of the obstacles currently in the service's data storage.
 These are objects designated for the robot to avoid when navigating.
 These include all transient obstacles which are discovered by the vision services configured for the navigation service, in addition to the obstacles that are configured as a part of the service.
-See the [motion service](/operate/reference/services/motion/) for more information.
+See the [motion service](/reference/services/motion/) for more information.
diff --git a/static/include/snippet/visualize.md b/static/include/snippet/visualize.md
index 798897804c..05af84a95b 100644
--- a/static/include/snippet/visualize.md
+++ b/static/include/snippet/visualize.md
@@ -1,7 +1,7 @@
 You can visualize your machine's geometries and frames in the Viam app:
 
 {{% alert title="Tip" color="tip" %}}
-To visualize a component without moving any real-world hardware, configure a `fake` model to represent your component (for example, a [`fake` arm](/operate/reference/components/arm/fake/)), then follow the steps below using the fake component.
+To visualize a component without moving any real-world hardware, configure a `fake` model to represent your component (for example, a [`fake` arm](/reference/components/arm/fake/)), then follow the steps below using the fake component.
 {{% /alert %}}
 
 1. In Viam, navigate to your machine's page.

From c179e36c90449be5200eaf2a879dd9d02cfa8eaf Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 16:09:09 -0400
Subject: [PATCH 7/8] Fix remaining htmltest failures
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Remove SLAM service row from data capture-supported include
- Drop #configuration anchor from board API include links
  (new board landing page does not have a configuration section)
- Fix #rotate-an-api-key anchor → #rotate-a-key on api-keys page

Local htmltest now passes with the CI config (.htmltest-local.yml).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 static/include/app/apis/generated/app.md                        | 2 +-
 static/include/app/apis/overrides/protos/app.RotateKey.md       | 2 +-
 static/include/components/apis/generated/board.md               | 2 +-
 .../overrides/methods/go.board.AnalogNames.string.return.md     | 2 +-
 .../methods/go.board.DigitalInterruptNames.string.return.md     | 2 +-
 .../apis/overrides/methods/go.board.GPIOPinByName.name.md       | 2 +-
 static/include/data/capture-supported.md                        | 1 -
 7 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/static/include/app/apis/generated/app.md b/static/include/app/apis/generated/app.md
index d3a3a2eba0..b7c164ae63 100644
--- a/static/include/app/apis/generated/app.md
+++ b/static/include/app/apis/generated/app.md
@@ -6045,7 +6045,7 @@ For more information, see the [TypeScript SDK Docs](https://ts.viam.dev/classes/
 
 ### RotateKey
 
-Rotate an [API key](/organization/api-keys/#rotate-an-api-key).
+Rotate an [API key](/organization/api-keys/#rotate-a-key).
 
 {{< tabs >}}
 {{% tab name="Python" %}}
diff --git a/static/include/app/apis/overrides/protos/app.RotateKey.md b/static/include/app/apis/overrides/protos/app.RotateKey.md
index 4c53e5784f..9c9491f268 100644
--- a/static/include/app/apis/overrides/protos/app.RotateKey.md
+++ b/static/include/app/apis/overrides/protos/app.RotateKey.md
@@ -1 +1 @@
-Rotate an [API key](/organization/api-keys/#rotate-an-api-key).
+Rotate an [API key](/organization/api-keys/#rotate-a-key).
diff --git a/static/include/components/apis/generated/board.md b/static/include/components/apis/generated/board.md
index f0bc68faac..a5317b2e82 100644
--- a/static/include/components/apis/generated/board.md
+++ b/static/include/components/apis/generated/board.md
@@ -1367,7 +1367,7 @@ For more information, see the [Python SDK Docs](https://python.viam.dev/autoapi/
 
 **Parameters:**
 
-- `name` [(string)](https://pkg.go.dev/builtin#string): Pin number of the GPIO pin you want to retrieve as a `GPIOPin` interface. Refer to the pinout diagram and data sheet of your [board model](/reference/components/board/#configuration) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
+- `name` [(string)](https://pkg.go.dev/builtin#string): Pin number of the GPIO pin you want to retrieve as a `GPIOPin` interface. Refer to the pinout diagram and data sheet of your [board model](/reference/components/board/) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
 
 **Returns:**
 
diff --git a/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md b/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md
index d9cc04e9c2..da9d27486d 100644
--- a/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md
+++ b/static/include/components/apis/overrides/methods/go.board.AnalogNames.string.return.md
@@ -1 +1 @@
-A slice containing the `"name"` of every analog pin [configured](/reference/components/board/#configuration) on the board.
+A slice containing the `"name"` of every analog pin [configured](/reference/components/board/) on the board.
diff --git a/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md b/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md
index b407c94ae4..3cccb939c2 100644
--- a/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md
+++ b/static/include/components/apis/overrides/methods/go.board.DigitalInterruptNames.string.return.md
@@ -1 +1 @@
-A slice containing the `"name"` of every interrupt [configured](/reference/components/board/#configuration) on the board.
+A slice containing the `"name"` of every interrupt [configured](/reference/components/board/) on the board.
diff --git a/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md b/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md
index b99cf60a44..a97194be5e 100644
--- a/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md
+++ b/static/include/components/apis/overrides/methods/go.board.GPIOPinByName.name.md
@@ -1,2 +1,2 @@
 Pin number of the GPIO pin you want to retrieve as a `GPIOPin` interface.
-Refer to the pinout diagram and data sheet of your [board model](/reference/components/board/#configuration) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
+Refer to the pinout diagram and data sheet of your [board model](/reference/components/board/) for {{< glossary_tooltip term_id="pin-number" text="pin numbers" >}}.
diff --git a/static/include/data/capture-supported.md b/static/include/data/capture-supported.md
index 54954b80c3..5105b06ef1 100644
--- a/static/include/data/capture-supported.md
+++ b/static/include/data/capture-supported.md
@@ -23,7 +23,6 @@
 | [Base remote control service](/reference/services/base-rc/) | `DoCommand` |
 | [Discovery service](/reference/services/discovery/)       | `DoCommand` |
 | [Vision service](/vision/configure/)             | `CaptureAllFromCamera`, `DoCommand` |
-| [SLAM service](/reference/services/slam/)                 | `Position`, `PointCloudMap`, `DoCommand` |
 | [Motion service](/reference/services/motion/)             | `DoCommand` |
 | [Navigation service](/reference/services/navigation/)     | `DoCommand` |
 | Shell service | `DoCommand` |

From 1c49f3ccac5f4170a2754f30fbb90fdda7a53e45 Mon Sep 17 00:00:00 2001
From: shannonbradshaw <shannon.bradshaw@gmail.com>
Date: Mon, 20 Apr 2026 16:22:01 -0400
Subject: [PATCH 8/8] Add operate/ aliases for component models, services, and
 skip patterns

Netlify no-more-404 plugin requires either alias or skipPattern for
130 paths that existed on production before operate/ deletion.

- Add /operate/reference/components/X/Y/ aliases to 43 component model
  pages (so URLs like /operate/reference/components/motor/encoded-motor/
  redirect to the new-IA equivalent)
- Add /operate/reference/components/servo/ alias to servo landing
- Add /operate/reference/services/X/ aliases to 5 service pages from #4978
- Extend skipPatterns in netlify.toml for paths intentionally without
  redirect: SLAM (deleted entirely), Hugo tag pages, old IA paths
  (architecture/, build/micro-rdk/, micro-rdk/, internals/), pre-cutover
  operate/ paths (get-started, hello-world, mobility, modules), and
  long-deleted tutorials

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 docs/reference/components/arm/fake.md                         | 1 +
 docs/reference/components/base/fake.md                        | 1 +
 docs/reference/components/base/sensor-controlled.md           | 1 +
 docs/reference/components/base/wheeled.md                     | 1 +
 docs/reference/components/board/fake.md                       | 1 +
 docs/reference/components/camera/fake.md                      | 1 +
 docs/reference/components/camera/ffmpeg.md                    | 1 +
 docs/reference/components/camera/image-file.md                | 1 +
 docs/reference/components/camera/transform.md                 | 1 +
 docs/reference/components/camera/webcam.md                    | 1 +
 docs/reference/components/encoder/fake.md                     | 1 +
 docs/reference/components/encoder/incremental.md              | 1 +
 docs/reference/components/encoder/micro-rdk/incremental.md    | 1 +
 docs/reference/components/encoder/micro-rdk/single.md         | 1 +
 docs/reference/components/encoder/single.md                   | 1 +
 docs/reference/components/gantry/fake.md                      | 1 +
 docs/reference/components/gantry/multi-axis.md                | 1 +
 docs/reference/components/gantry/single-axis.md               | 1 +
 docs/reference/components/generic/fake.md                     | 1 +
 docs/reference/components/gripper/fake.md                     | 1 +
 docs/reference/components/input-controller/fake.md            | 1 +
 docs/reference/components/input-controller/gamepad.md         | 1 +
 docs/reference/components/input-controller/gpio.md            | 1 +
 docs/reference/components/input-controller/mux.md             | 1 +
 docs/reference/components/input-controller/webgamepad.md      | 1 +
 docs/reference/components/motor/dmc4000.md                    | 1 +
 docs/reference/components/motor/encoded-motor.md              | 1 +
 docs/reference/components/motor/fake.md                       | 1 +
 docs/reference/components/motor/gpio.md                       | 1 +
 docs/reference/components/motor/gpiostepper.md                | 1 +
 docs/reference/components/motor/micro-rdk/gpio.md             | 1 +
 docs/reference/components/movement-sensor/fake.md             | 1 +
 docs/reference/components/movement-sensor/merged.md           | 1 +
 .../components/movement-sensor/micro-rdk/accel-adxl345.md     | 1 +
 .../components/movement-sensor/micro-rdk/gyro-mpu6050.md      | 1 +
 docs/reference/components/movement-sensor/wheeled-odometry.md | 1 +
 docs/reference/components/power-sensor/fake.md                | 1 +
 docs/reference/components/sensor/fake.md                      | 1 +
 docs/reference/components/sensor/micro-rdk/ultrasonic.md      | 1 +
 docs/reference/components/servo/_index.md                     | 1 +
 docs/reference/components/servo/fake.md                       | 1 +
 docs/reference/components/servo/gpio.md                       | 1 +
 docs/reference/components/servo/micro-rdk/gpio.md             | 1 +
 docs/reference/components/switch/fake.md                      | 1 +
 docs/reference/services/base-rc/_index.md                     | 1 +
 docs/reference/services/discovery/_index.md                   | 2 ++
 docs/reference/services/frame-system/_index.md                | 1 +
 docs/reference/services/generic/_index.md                     | 1 +
 docs/reference/services/generic/fake.md                       | 1 +
 docs/reference/services/navigation/_index.md                  | 1 +
 netlify.toml                                                  | 4 ++--
 51 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/docs/reference/components/arm/fake.md b/docs/reference/components/arm/fake.md
index 8d83f4e4db..9148bf5083 100644
--- a/docs/reference/components/arm/fake.md
+++ b/docs/reference/components/arm/fake.md
@@ -7,6 +7,7 @@ description: "Reference for the fake arm model. Fake arm to use for testing."
 images: ["/icons/components/arm.svg"]
 tags: ["arm", "components"]
 aliases:
+  - "/operate/reference/components/arm/fake/"
   - "/components/arm/fake/"
   - "/reference/components/arm/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/base/fake.md b/docs/reference/components/base/fake.md
index c6e1b21d1a..50cdcdd11b 100644
--- a/docs/reference/components/base/fake.md
+++ b/docs/reference/components/base/fake.md
@@ -7,6 +7,7 @@ description: "Reference for the fake base model. Fake base to use for testing wi
 images: ["/icons/components/base.svg"]
 tags: ["base", "components"]
 aliases:
+  - "/operate/reference/components/base/fake/"
   - "/components/base/fake/"
   - "/reference/components/base/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/base/sensor-controlled.md b/docs/reference/components/base/sensor-controlled.md
index baa2fbe689..2078699586 100644
--- a/docs/reference/components/base/sensor-controlled.md
+++ b/docs/reference/components/base/sensor-controlled.md
@@ -7,6 +7,7 @@ description: "Reference for the sensor-controlled base model. Sensor-controlled
 images: ["/icons/components/base.svg"]
 tags: ["base", "components"]
 aliases:
+  - "/operate/reference/components/base/sensor-controlled/"
   - "/components/base/sensor-controlled/"
   - "/reference/components/base/sensor-controlled/"
 component_description: "Wrap other base models and add feedback control using a movement sensor."
diff --git a/docs/reference/components/base/wheeled.md b/docs/reference/components/base/wheeled.md
index 095fa05607..d054068515 100644
--- a/docs/reference/components/base/wheeled.md
+++ b/docs/reference/components/base/wheeled.md
@@ -7,6 +7,7 @@ description: "Reference for the wheeled base model. And wire a wheeled base."
 images: ["/icons/components/base.svg"]
 tags: ["base", "components"]
 aliases:
+  - "/operate/reference/components/base/wheeled/"
   - "/components/base/wheeled/"
   - "/reference/components/base/wheeled/"
 component_description: "Supports mobile wheeled robotic bases with motors on both sides for differential steering."
diff --git a/docs/reference/components/board/fake.md b/docs/reference/components/board/fake.md
index 0531c9e2d3..d922202eb4 100644
--- a/docs/reference/components/board/fake.md
+++ b/docs/reference/components/board/fake.md
@@ -7,6 +7,7 @@ description: "Reference for the fake board model. Fake board."
 images: ["/icons/components/board.svg"]
 tags: ["board", "components"]
 aliases:
+  - "/operate/reference/components/board/fake/"
   - "/components/board/fake/"
   - "/reference/components/board/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/camera/fake.md b/docs/reference/components/camera/fake.md
index 0e229ded9d..f7d2dce00d 100644
--- a/docs/reference/components/camera/fake.md
+++ b/docs/reference/components/camera/fake.md
@@ -7,6 +7,7 @@ description: "Reference for the fake camera model. Returns a static gradient ima
 images: ["/icons/components/camera.svg"]
 tags: ["camera", "components"]
 aliases:
+  - "/operate/reference/components/camera/fake/"
   - "/components/camera/fake/"
   - "/reference/components/camera/fake/"
 component_description: "A camera model for testing."
diff --git a/docs/reference/components/camera/ffmpeg.md b/docs/reference/components/camera/ffmpeg.md
index c87ef965f0..e55b6aa136 100644
--- a/docs/reference/components/camera/ffmpeg.md
+++ b/docs/reference/components/camera/ffmpeg.md
@@ -7,6 +7,7 @@ description: "Reference for the ffmpeg camera model. Uses a camera device, video
 images: ["/icons/components/camera.svg"]
 tags: ["camera", "components"]
 aliases:
+  - "/operate/reference/components/camera/ffmpeg/"
   - "/components/camera/ffmpeg/"
   - "/reference/components/camera/ffmpeg/"
 component_description: "Use a camera, a video file, or a stream as a camera component."
diff --git a/docs/reference/components/camera/image-file.md b/docs/reference/components/camera/image-file.md
index c23eeb1cb4..2036126db2 100644
--- a/docs/reference/components/camera/image-file.md
+++ b/docs/reference/components/camera/image-file.md
@@ -7,6 +7,7 @@ description: "Reference for the image_file camera model. Serves color or depth i
 images: ["/icons/components/camera.svg"]
 tags: ["camera", "components"]
 aliases:
+  - "/operate/reference/components/camera/image-file/"
   - "/components/camera/image-file/"
   - "/reference/components/camera/image-file/"
 component_description: "Gets color and depth image frames from a file path."
diff --git a/docs/reference/components/camera/transform.md b/docs/reference/components/camera/transform.md
index 2d27092f04..0c5fdba05e 100644
--- a/docs/reference/components/camera/transform.md
+++ b/docs/reference/components/camera/transform.md
@@ -7,6 +7,7 @@ description: "Reference for the transform camera model. Apply pipeline transform
 images: ["/icons/components/camera.svg"]
 tags: ["camera", "components"]
 aliases:
+  - "/operate/reference/components/camera/transform/"
   - "/components/camera/transform/"
   - "/reference/components/camera/transform/"
 component_description: "Use pipelines for applying transformations to an input image source."
diff --git a/docs/reference/components/camera/webcam.md b/docs/reference/components/camera/webcam.md
index c2509b774b..dd919a36bf 100644
--- a/docs/reference/components/camera/webcam.md
+++ b/docs/reference/components/camera/webcam.md
@@ -7,6 +7,7 @@ description: "Reference for the webcam camera model. The general camera model fo
 images: ["/icons/components/camera.svg"]
 tags: ["camera", "components"]
 aliases:
+  - "/operate/reference/components/camera/webcam/"
   - "/components/camera/webcam/"
   - "/reference/components/camera/webcam/"
 component_description: "A standard USB camera or other webcam that streams camera data."
diff --git a/docs/reference/components/encoder/fake.md b/docs/reference/components/encoder/fake.md
index b644329df3..f5921f171f 100644
--- a/docs/reference/components/encoder/fake.md
+++ b/docs/reference/components/encoder/fake.md
@@ -7,6 +7,7 @@ images: ["/icons/components/encoder.svg"]
 tags: ["encoder", "components"]
 weight: 10
 aliases:
+  - "/operate/reference/components/encoder/fake/"
   - "/components/encoder/fake/"
   - "/reference/components/encoder/fake/"
 component_description: "An encoder model for testing."
diff --git a/docs/reference/components/encoder/incremental.md b/docs/reference/components/encoder/incremental.md
index 2103309a9b..83dce5c96c 100644
--- a/docs/reference/components/encoder/incremental.md
+++ b/docs/reference/components/encoder/incremental.md
@@ -6,6 +6,7 @@ description: "Reference for the incremental encoder model. Incremental encoder."
 images: ["/icons/components/encoder.svg"]
 tags: ["encoder", "components"]
 aliases:
+  - "/operate/reference/components/encoder/incremental/"
   - "/components/encoder/incremental/"
   - "/reference/components/encoder/incremental/"
 component_description: "Supports a two phase encoder, which can measure the speed and direction of rotation in relation to a given reference point."
diff --git a/docs/reference/components/encoder/micro-rdk/incremental.md b/docs/reference/components/encoder/micro-rdk/incremental.md
index fb7784e8c7..c9c724c20d 100644
--- a/docs/reference/components/encoder/micro-rdk/incremental.md
+++ b/docs/reference/components/encoder/micro-rdk/incremental.md
@@ -7,6 +7,7 @@ description: "Reference for the incremental encoder model. Incremental encoder."
 images: ["/icons/components/encoder.svg"]
 tags: ["encoder", "components"]
 aliases:
+  - "/operate/reference/components/encoder/incremental-micro-rdk/"
   - /micro-rdk/encoder/incremental/
   - /build/micro-rdk/encoder/incremental/
   - /components/encoder/incremental-micro-rdk/
diff --git a/docs/reference/components/encoder/micro-rdk/single.md b/docs/reference/components/encoder/micro-rdk/single.md
index 5a14ad9aba..95a1b54a08 100644
--- a/docs/reference/components/encoder/micro-rdk/single.md
+++ b/docs/reference/components/encoder/micro-rdk/single.md
@@ -6,6 +6,7 @@ description: "Reference for the single encoder model. Single encoder with a micr
 images: ["/icons/components/encoder.svg"]
 tags: ["encoder", "components"]
 aliases:
+  - "/operate/reference/components/encoder/single-micro-rdk/"
   - /micro-rdk/encoder/single/
   - /build/micro-rdk/encoder/single/
   - /components/encoder/single-micro-rdk/
diff --git a/docs/reference/components/encoder/single.md b/docs/reference/components/encoder/single.md
index 68e95c1b5f..624fabf0e4 100644
--- a/docs/reference/components/encoder/single.md
+++ b/docs/reference/components/encoder/single.md
@@ -6,6 +6,7 @@ description: "Reference for the single encoder model. Single encoder."
 images: ["/icons/components/encoder.svg"]
 tags: ["encoder", "components"]
 aliases:
+  - "/operate/reference/components/encoder/single/"
   - "/components/encoder/single/"
   - "/reference/components/encoder/single/"
 component_description: "A single pin 'pulse output' encoder which returns its relative position but no direction."
diff --git a/docs/reference/components/gantry/fake.md b/docs/reference/components/gantry/fake.md
index cff87ac307..d6c98f43c4 100644
--- a/docs/reference/components/gantry/fake.md
+++ b/docs/reference/components/gantry/fake.md
@@ -8,6 +8,7 @@ tags: ["gantry", "components"]
 icon: true
 images: ["/icons/components/gantry.svg"]
 aliases:
+  - "/operate/reference/components/gantry/fake/"
   - "/components/gantry/fake/"
   - "/reference/components/gantry/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/gantry/multi-axis.md b/docs/reference/components/gantry/multi-axis.md
index 6594a9907c..9ee27622c8 100644
--- a/docs/reference/components/gantry/multi-axis.md
+++ b/docs/reference/components/gantry/multi-axis.md
@@ -7,6 +7,7 @@ description: "Reference for the multi-axis gantry model. Multi-axis gantry."
 images: ["/icons/components/gantry.svg"]
 tags: ["gantry", "components"]
 aliases:
+  - "/operate/reference/components/gantry/multi-axis/"
   - "/components/gantry/multiaxis/"
   - "/components/gantry/multi-axis/"
   - "/reference/components/gantry/multi-axis/"
diff --git a/docs/reference/components/gantry/single-axis.md b/docs/reference/components/gantry/single-axis.md
index 3e6b2181dd..a493d532c2 100644
--- a/docs/reference/components/gantry/single-axis.md
+++ b/docs/reference/components/gantry/single-axis.md
@@ -7,6 +7,7 @@ description: "Reference for the single-axis gantry model. Single-axis gantry."
 images: ["/icons/components/gantry.svg"]
 tags: ["gantry", "components"]
 aliases:
+  - "/operate/reference/components/gantry/single-axis/"
   - "/components/gantry/oneaxis/"
   - "/components/gantry/single-axis/"
   - "/reference/components/gantry/single-axis/"
diff --git a/docs/reference/components/generic/fake.md b/docs/reference/components/generic/fake.md
index 9365b8c17e..424773b0a4 100644
--- a/docs/reference/components/generic/fake.md
+++ b/docs/reference/components/generic/fake.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the fake generic model. Fake generic component."
 tags: ["generic", "components"]
 aliases:
+  - "/operate/reference/components/generic/fake/"
   - "/components/generic/fake/"
   - "/reference/components/generic/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/gripper/fake.md b/docs/reference/components/gripper/fake.md
index 1c61e3c60e..74c8191435 100644
--- a/docs/reference/components/gripper/fake.md
+++ b/docs/reference/components/gripper/fake.md
@@ -8,6 +8,7 @@ tags: ["gripper", "components"]
 icon: true
 images: ["/icons/components/gripper.svg"]
 aliases:
+  - "/operate/reference/components/gripper/fake/"
   - "/components/gripper/fake/"
   - "/reference/components/gripper/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/input-controller/fake.md b/docs/reference/components/input-controller/fake.md
index d4af261a55..97d75869db 100644
--- a/docs/reference/components/input-controller/fake.md
+++ b/docs/reference/components/input-controller/fake.md
@@ -7,6 +7,7 @@ description: "Reference for the fake input-controller model. Fake input controll
 images: ["/icons/components/controller.svg"]
 tags: ["input controller", "components"]
 aliases:
+  - "/operate/reference/components/input-controller/fake/"
   - "/components/input-controller/fake/"
   - "/reference/components/input-controller/fake/"
 component_description: "A model for testing, with no physical hardware."
diff --git a/docs/reference/components/input-controller/gamepad.md b/docs/reference/components/input-controller/gamepad.md
index 5fc0765350..718559a191 100644
--- a/docs/reference/components/input-controller/gamepad.md
+++ b/docs/reference/components/input-controller/gamepad.md
@@ -7,6 +7,7 @@ description: "Reference for the gamepad input-controller model. Linux-supported
 images: ["/icons/components/controller.svg"]
 tags: ["input controller", "components"]
 aliases:
+  - "/operate/reference/components/input-controller/gamepad/"
   - "/components/input-controller/gamepad/"
   - "/reference/components/input-controller/gamepad/"
 component_description: "Supports X-box, Playstation, and similar controllers with Linux support."
diff --git a/docs/reference/components/input-controller/gpio.md b/docs/reference/components/input-controller/gpio.md
index 36dd4c6bf0..edec37bd83 100644
--- a/docs/reference/components/input-controller/gpio.md
+++ b/docs/reference/components/input-controller/gpio.md
@@ -7,6 +7,7 @@ description: "Reference for the gpio input-controller model. GPIO- or ADC-based
 images: ["/icons/components/controller.svg"]
 tags: ["input controller", "components"]
 aliases:
+  - "/operate/reference/components/input-controller/gpio/"
   - "/components/input-controller/gpio/"
   - "/reference/components/input-controller/gpio/"
 component_description: "Customizable GPIO/ADC based device using a board component."
diff --git a/docs/reference/components/input-controller/mux.md b/docs/reference/components/input-controller/mux.md
index 6cfc01a9a7..6796898f7d 100644
--- a/docs/reference/components/input-controller/mux.md
+++ b/docs/reference/components/input-controller/mux.md
@@ -7,6 +7,7 @@ description: "Reference for the mux input-controller model. Mux input controller
 images: ["/icons/components/controller.svg"]
 tags: ["input controller", "components"]
 aliases:
+  - "/operate/reference/components/input-controller/mux/"
   - "/components/input-controller/mux/"
   - "/reference/components/input-controller/mux/"
 component_description: "Supports multiplexed controllers, combining multiple sources of input."
diff --git a/docs/reference/components/input-controller/webgamepad.md b/docs/reference/components/input-controller/webgamepad.md
index d7beb2d5ab..4b04d9951a 100644
--- a/docs/reference/components/input-controller/webgamepad.md
+++ b/docs/reference/components/input-controller/webgamepad.md
@@ -7,6 +7,7 @@ description: "Reference for the webgamepad input-controller model. Web-based gam
 images: ["/icons/components/controller.svg"]
 tags: ["input controller", "components"]
 aliases:
+  - "/operate/reference/components/input-controller/webgamepad/"
   - "/components/input-controller/webgamepad/"
   - "/reference/components/input-controller/webgamepad/"
 component_description: "Supports a remote, web based gamepad."
diff --git a/docs/reference/components/motor/dmc4000.md b/docs/reference/components/motor/dmc4000.md
index 42188088a7..d28ff99633 100644
--- a/docs/reference/components/motor/dmc4000.md
+++ b/docs/reference/components/motor/dmc4000.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the dmc4000 motor model. Stepper motor controlled by a DMC-40x0 series motion controller."
 images: ["/icons/components/motor.svg"]
 aliases:
+  - "/operate/reference/components/motor/dmc4000/"
   - "/components/motor/dmc4000/"
   - "/reference/components/motor/dmc4000/"
 component_description: "Stepper motor driven by a DMC-40x0 series motion controller."
diff --git a/docs/reference/components/motor/encoded-motor.md b/docs/reference/components/motor/encoded-motor.md
index 36ac2189d1..cab2ef0e0b 100644
--- a/docs/reference/components/motor/encoded-motor.md
+++ b/docs/reference/components/motor/encoded-motor.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the encoded-motor motor model. How to configure an encoded motor."
 images: ["/icons/components/motor.svg"]
 aliases:
+  - "/operate/reference/components/motor/encoded-motor/"
   - "/components/motor/gpio/encoded-motor/"
   - "/reference/components/motor/encoded-motor/"
 component_description: "Standard brushed or brushless DC motor with an encoder."
diff --git a/docs/reference/components/motor/fake.md b/docs/reference/components/motor/fake.md
index a731249ff7..5d820631d2 100644
--- a/docs/reference/components/motor/fake.md
+++ b/docs/reference/components/motor/fake.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the fake motor model. Fake motor to test software without any hardware."
 images: ["/icons/components/motor.svg"]
 aliases:
+  - "/operate/reference/components/motor/fake/"
   - "/components/motor/fake/"
   - "/reference/components/motor/fake/"
 component_description: "A model for testing, with no physical hardware."
diff --git a/docs/reference/components/motor/gpio.md b/docs/reference/components/motor/gpio.md
index f142cb46af..31245e3978 100644
--- a/docs/reference/components/motor/gpio.md
+++ b/docs/reference/components/motor/gpio.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the gpio motor model. Brushed or brushless DC motors."
 images: ["/icons/components/motor.svg"]
 aliases:
+  - "/operate/reference/components/motor/gpio/"
   - "/components/motor/gpio/"
   - "/reference/components/motor/gpio/"
 no_list: true
diff --git a/docs/reference/components/motor/gpiostepper.md b/docs/reference/components/motor/gpiostepper.md
index 8d9b2ed471..a879323a64 100644
--- a/docs/reference/components/motor/gpiostepper.md
+++ b/docs/reference/components/motor/gpiostepper.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the gpiostepper motor model. Bipolar stepper motor with current regulation and 1/32 microstepping driven by a basic driver."
 images: ["/icons/components/motor.svg"]
 aliases:
+  - "/operate/reference/components/motor/gpiostepper/"
   - "/components/motor/gpiostepper/"
   - "/reference/components/motor/gpiostepper/"
 component_description: "Supports stepper motors driven by basic GPIO-controlled stepper driver chips."
diff --git a/docs/reference/components/motor/micro-rdk/gpio.md b/docs/reference/components/motor/micro-rdk/gpio.md
index f73035b540..4d14c9a36b 100644
--- a/docs/reference/components/motor/micro-rdk/gpio.md
+++ b/docs/reference/components/motor/micro-rdk/gpio.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the gpio motor model. Brushed or brushless DC motors with a microcontroller."
 images: ["/icons/components/motor.svg"]
 aliases:
+  - "/operate/reference/components/motor/gpio-micro-rdk/"
   - /micro-rdk/motor/gpio/
   - /components/motor/gpio-micro-rdk/
   - "/reference/components/motor/gpio-micro-rdk/"
diff --git a/docs/reference/components/movement-sensor/fake.md b/docs/reference/components/movement-sensor/fake.md
index 32db651b82..fe3f820d50 100644
--- a/docs/reference/components/movement-sensor/fake.md
+++ b/docs/reference/components/movement-sensor/fake.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the fake movement-sensor model. Fake movement sensor to test software without any hardware."
 images: ["/icons/components/imu.svg"]
 aliases:
+  - "/operate/reference/components/movement-sensor/fake/"
   - "/components/movement-sensor/fake/"
   - "/reference/components/movement-sensor/fake/"
 component_description: "A model for testing, with no physical hardware."
diff --git a/docs/reference/components/movement-sensor/merged.md b/docs/reference/components/movement-sensor/merged.md
index 6a90d341b1..ade9516c1d 100644
--- a/docs/reference/components/movement-sensor/merged.md
+++ b/docs/reference/components/movement-sensor/merged.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the merged movement-sensor model. Merged movement sensor."
 images: ["/icons/components/imu.svg"]
 aliases:
+  - "/operate/reference/components/movement-sensor/merged/"
   - "/components/movement-sensor/merged/"
   - "/reference/components/movement-sensor/merged/"
 component_description: "A model that allows you to aggregate the API methods supported by multiple sensors into a singular sensor client, effectively merging the models of the individual resources."
diff --git a/docs/reference/components/movement-sensor/micro-rdk/accel-adxl345.md b/docs/reference/components/movement-sensor/micro-rdk/accel-adxl345.md
index 8bac2254ca..7e612ff81f 100644
--- a/docs/reference/components/movement-sensor/micro-rdk/accel-adxl345.md
+++ b/docs/reference/components/movement-sensor/micro-rdk/accel-adxl345.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "Reference for the accel-adxl345 movement-sensor model. ADXL345 digital accelerometer with a microcontroller."
 images: ["/icons/components/imu.svg"]
 aliases:
+  - "/operate/reference/components/movement-sensor/accel-adxl345-micro-rdk/"
   - /micro-rdk/movement-sensor/accel-adxl345/
   - /components/movement-sensor/accel-adxl345-micro-rdk/
   - "/reference/components/movement-sensor/accel-adxl345-micro-rdk/"
diff --git a/docs/reference/components/movement-sensor/micro-rdk/gyro-mpu6050.md b/docs/reference/components/movement-sensor/micro-rdk/gyro-mpu6050.md
index e60c934550..3ccb749c1d 100644
--- a/docs/reference/components/movement-sensor/micro-rdk/gyro-mpu6050.md
+++ b/docs/reference/components/movement-sensor/micro-rdk/gyro-mpu6050.md
@@ -6,6 +6,7 @@ type: "docs"
 description: "Reference for the gyro-mpu6050 movement-sensor model. MPU-6050 movement sensor with a microcontroller."
 images: ["/icons/components/imu.svg"]
 aliases:
+  - "/operate/reference/components/movement-sensor/gyro-mpu6050-micro-rdk/"
   - /micro-rdk/movement-sensor/gyro-mpu6050/
   - /build/micro-rdk/movement-sensor/gyro-mpu6050/
   - /components/movement-sensor/gyro-mpu6050-micro-rdk/
diff --git a/docs/reference/components/movement-sensor/wheeled-odometry.md b/docs/reference/components/movement-sensor/wheeled-odometry.md
index 166e5719bc..efe3ea8a4f 100644
--- a/docs/reference/components/movement-sensor/wheeled-odometry.md
+++ b/docs/reference/components/movement-sensor/wheeled-odometry.md
@@ -15,6 +15,7 @@ tags:
     "odometry",
   ]
 aliases:
+  - "/operate/reference/components/movement-sensor/wheeled-odometry/"
   - "/components/movement-sensor/wheeled-odometry/"
   - "/reference/components/movement-sensor/wheeled-odometry/"
 component_description: "A model that uses encoders to get an odometry estimate from a wheeled base."
diff --git a/docs/reference/components/power-sensor/fake.md b/docs/reference/components/power-sensor/fake.md
index bed51a5674..134c7e0978 100644
--- a/docs/reference/components/power-sensor/fake.md
+++ b/docs/reference/components/power-sensor/fake.md
@@ -8,6 +8,7 @@ tags: ["sensor", "power sensor"]
 icon: true
 images: ["/icons/components/sensor.svg"]
 aliases:
+  - "/operate/reference/components/power-sensor/fake/"
   - "/components/power-sensor/fake/"
   - "/reference/components/power-sensor/fake/"
 component_description: "A model for testing, with no physical hardware."
diff --git a/docs/reference/components/sensor/fake.md b/docs/reference/components/sensor/fake.md
index 3fa256d4a8..c00372597b 100644
--- a/docs/reference/components/sensor/fake.md
+++ b/docs/reference/components/sensor/fake.md
@@ -8,6 +8,7 @@ tags: ["sensor", "components"]
 icon: true
 images: ["/icons/components/sensor.svg"]
 aliases:
+  - "/operate/reference/components/sensor/fake/"
   - "/components/sensor/fake/"
   - "/reference/components/sensor/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/sensor/micro-rdk/ultrasonic.md b/docs/reference/components/sensor/micro-rdk/ultrasonic.md
index 4e092da455..bd25e57bfd 100644
--- a/docs/reference/components/sensor/micro-rdk/ultrasonic.md
+++ b/docs/reference/components/sensor/micro-rdk/ultrasonic.md
@@ -9,6 +9,7 @@ icon: true
 images: ["/icons/components/sensor.svg"]
 micrordk_component: true
 aliases:
+  - "/operate/reference/components/sensor/ultrasonic-micro-rdk/"
   - /build/micro-rdk/sensor/ultrasonic/
   - /components/sensor/ultrasonic-micro-rdk/
   - "/reference/components/sensor/ultrasonic-micro-rdk/"
diff --git a/docs/reference/components/servo/_index.md b/docs/reference/components/servo/_index.md
index ecc30a1b59..3b88b7da61 100644
--- a/docs/reference/components/servo/_index.md
+++ b/docs/reference/components/servo/_index.md
@@ -12,6 +12,7 @@ images: ["/icons/components/servo.svg"]
 aliases:
   - "/components/servo/"
   - "/reference/components/servo/"
+  - "/operate/reference/components/servo/"
 ---
 
 This section documents the configuration attributes for each built-in servo model.
diff --git a/docs/reference/components/servo/fake.md b/docs/reference/components/servo/fake.md
index f8f23a4de0..bbdf00269d 100644
--- a/docs/reference/components/servo/fake.md
+++ b/docs/reference/components/servo/fake.md
@@ -8,6 +8,7 @@ tags: ["servo", "components"]
 icon: true
 images: ["/icons/components/servo.svg"]
 aliases:
+  - "/operate/reference/components/servo/fake/"
   - "/components/servo/fake/"
   - "/reference/components/servo/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/components/servo/gpio.md b/docs/reference/components/servo/gpio.md
index e6d503c8d7..3da7eb9319 100644
--- a/docs/reference/components/servo/gpio.md
+++ b/docs/reference/components/servo/gpio.md
@@ -8,6 +8,7 @@ tags: ["servo", "components"]
 icon: true
 images: ["/icons/components/servo.svg"]
 aliases:
+  - "/operate/reference/components/servo/gpio/"
   - "/components/servo/gpio/"
   - "/reference/components/servo/gpio/"
 component_description: "Supports a hobby servo wired to a board that supports PWM, for example Raspberry Pi 5, Orange Pi, Jetson, or PCAXXXX."
diff --git a/docs/reference/components/servo/micro-rdk/gpio.md b/docs/reference/components/servo/micro-rdk/gpio.md
index 64d09d5fbe..9919754721 100644
--- a/docs/reference/components/servo/micro-rdk/gpio.md
+++ b/docs/reference/components/servo/micro-rdk/gpio.md
@@ -8,6 +8,7 @@ tags: ["servo", "components"]
 icon: true
 images: ["/icons/components/servo.svg"]
 aliases:
+  - "/operate/reference/components/servo/gpio-micro-rdk/"
   - /micro-rdk/servo/gpio/
   - /build/micro-rdk/servo/gpio/
   - /components/servo/gpio-micro-rdk/
diff --git a/docs/reference/components/switch/fake.md b/docs/reference/components/switch/fake.md
index 0a34aedfea..8b218fa831 100644
--- a/docs/reference/components/switch/fake.md
+++ b/docs/reference/components/switch/fake.md
@@ -7,6 +7,7 @@ description: "Reference for the fake switch model. Fake switch for testing."
 images: ["/icons/components/switch.svg"]
 tags: ["switch", "components"]
 aliases:
+  - "/operate/reference/components/switch/fake/"
   - "/components/switch/fake/"
   - "/reference/components/switch/fake/"
 component_description: "A model used for testing, with no physical hardware."
diff --git a/docs/reference/services/base-rc/_index.md b/docs/reference/services/base-rc/_index.md
index f31d82590a..3022ce6489 100644
--- a/docs/reference/services/base-rc/_index.md
+++ b/docs/reference/services/base-rc/_index.md
@@ -7,6 +7,7 @@ type: "docs"
 description: "The base remote control service allows you to remotely control a base with an input controller like a gamepad."
 date: "2026-04-18"
 aliases:
+  - "/operate/reference/services/base-rc/"
   - /services/base-rc/
   - /mobility/base-rc/
 ---
diff --git a/docs/reference/services/discovery/_index.md b/docs/reference/services/discovery/_index.md
index 36a02c57e8..0623d2d1f1 100644
--- a/docs/reference/services/discovery/_index.md
+++ b/docs/reference/services/discovery/_index.md
@@ -7,6 +7,8 @@ type: "docs"
 weight: 50
 modulescript: true
 date: "2026-04-18"
+aliases:
+  - "/operate/reference/services/discovery/"
 ---
 
 A discovery service allows you to return a list of physical hardware available on a machine, and suggest configurations for those components to integrate the hardware into the machine.
diff --git a/docs/reference/services/frame-system/_index.md b/docs/reference/services/frame-system/_index.md
index e7f515e0c3..4c80b5d280 100644
--- a/docs/reference/services/frame-system/_index.md
+++ b/docs/reference/services/frame-system/_index.md
@@ -7,6 +7,7 @@ type: "docs"
 weight: 50
 date: "2026-04-18"
 aliases:
+  - "/operate/reference/services/frame-system/"
   - /services/frame-system/
   - /services/frame-system/frame-config/
   - /mobility/frame-system/
diff --git a/docs/reference/services/generic/_index.md b/docs/reference/services/generic/_index.md
index 5e33312118..328a0f20da 100644
--- a/docs/reference/services/generic/_index.md
+++ b/docs/reference/services/generic/_index.md
@@ -8,6 +8,7 @@ description: "A service that does not fit any of the other APIs."
 modulescript: true
 date: "2026-04-18"
 aliases:
+  - "/operate/reference/services/generic/"
   - /registry/advanced/generic/
 ---
 
diff --git a/docs/reference/services/generic/fake.md b/docs/reference/services/generic/fake.md
index 02f8b3a434..989115d48d 100644
--- a/docs/reference/services/generic/fake.md
+++ b/docs/reference/services/generic/fake.md
@@ -7,6 +7,7 @@ description: "Configure a fake generic service using the generic service API."
 service_description: "A model used for testing a generic service."
 tags: ["generic", "services"]
 aliases:
+  - "/operate/reference/services/generic/fake/"
   - /registry/advanced/generic/fake/
   - /services/generic/fake/
 toc_hide: true
diff --git a/docs/reference/services/navigation/_index.md b/docs/reference/services/navigation/_index.md
index 11064890ed..d1b38ce8c9 100644
--- a/docs/reference/services/navigation/_index.md
+++ b/docs/reference/services/navigation/_index.md
@@ -7,6 +7,7 @@ type: "docs"
 weight: 50
 date: "2026-04-18"
 aliases:
+  - "/operate/reference/services/navigation/"
   - /services/navigation/
   - /mobility/navigation/
 ---
diff --git a/netlify.toml b/netlify.toml
index b02f7d7d32..f5ec691f3d 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -206,7 +206,7 @@
 
   failBuildOnError = true
   failPluginOnError = true
-  skipPatterns = ["/dev/", "/reference/components/", "/reference/services/", "/reference/account/", "/reference/advanced-modules/", "/reference/glossary_tmp/", "/reference/module-configuration/", "/reference/configuration/"]
+  skipPatterns = ["/dev/", "/reference/components/", "/reference/services/", "/reference/account/", "/reference/advanced-modules/", "/reference/glossary_tmp/", "/reference/module-configuration/", "/reference/configuration/", "/tags/", "/services/slam/", "/mobility/slam/", "/operate/reference/services/slam/", "/architecture/", "/build/micro-rdk/", "/micro-rdk/", "/internals/", "/components/camera/calibrate/", "/components/movement-sensor/set-up-base-station/", "/operate/get-started/", "/operate/hello-world/", "/operate/mobility/", "/operate/modules/", "/operate/reference/module-configuration/", "/operate/reference/naming-modules/", "/operate/reference/services/frame-system/frame-config/", "/tutorials/build-a-mock-robot/", "/tutorials/configure/build-a-mock-robot/", "/tutorials/configure-a-camera/", "/tutorials/how-to-build-a-mock-robot/"]
 
 
 [[context.branch-deploy.plugins]]
@@ -216,4 +216,4 @@
 
   failBuildOnError = true
   failPluginOnError = true
-  skipPatterns = ["/dev/", "/reference/components/", "/reference/services/", "/reference/account/", "/reference/advanced-modules/", "/reference/glossary_tmp/", "/reference/module-configuration/", "/reference/configuration/"]
+  skipPatterns = ["/dev/", "/reference/components/", "/reference/services/", "/reference/account/", "/reference/advanced-modules/", "/reference/glossary_tmp/", "/reference/module-configuration/", "/reference/configuration/", "/tags/", "/services/slam/", "/mobility/slam/", "/operate/reference/services/slam/", "/architecture/", "/build/micro-rdk/", "/micro-rdk/", "/internals/", "/components/camera/calibrate/", "/components/movement-sensor/set-up-base-station/", "/operate/get-started/", "/operate/hello-world/", "/operate/mobility/", "/operate/modules/", "/operate/reference/module-configuration/", "/operate/reference/naming-modules/", "/operate/reference/services/frame-system/frame-config/", "/tutorials/build-a-mock-robot/", "/tutorials/configure/build-a-mock-robot/", "/tutorials/configure-a-camera/", "/tutorials/how-to-build-a-mock-robot/"]