From c06f0a8cc7459e0dd67515ffe6af18e9ebfddd8b Mon Sep 17 00:00:00 2001
From: JessamyT <75634662+JessamyT@users.noreply.github.com>
Date: Tue, 7 Jan 2025 20:30:43 -0800
Subject: [PATCH] DOCS-3334: Add back advanced modular resources, and add
aliases (#3813)
---
docs/data-ai/ai/deploy.md | 10 +-
docs/dev/reference/glossary/part.md | 2 +-
docs/dev/reference/glossary/resource.md | 2 +-
docs/dev/reference/sdks/use-extra-params.md | 2 +-
.../get-started/other-hardware/cpp-module.md | 2 +-
.../reference/advanced-modules/_index.md | 53 ++++++++
.../advanced-modules/create-subtype.md | 107 +++++++++++++++
.../custom-components-remotes.md | 72 ++++++++++
.../advanced-modules/mlmodel-design.md | 128 ++++++++++++++++++
.../operate/reference/module-configuration.md | 2 +-
.../services/slam/cloudslam/_index.md | 2 +-
11 files changed, 375 insertions(+), 7 deletions(-)
create mode 100644 docs/operate/reference/advanced-modules/_index.md
create mode 100644 docs/operate/reference/advanced-modules/create-subtype.md
create mode 100644 docs/operate/reference/advanced-modules/custom-components-remotes.md
create mode 100644 docs/operate/reference/advanced-modules/mlmodel-design.md
diff --git a/docs/data-ai/ai/deploy.md b/docs/data-ai/ai/deploy.md
index b7c7ae66c3..e129e82e9e 100644
--- a/docs/data-ai/ai/deploy.md
+++ b/docs/data-ai/ai/deploy.md
@@ -9,6 +9,14 @@ description: "The Machine Learning (ML) model service allows you to deploy machi
aliases:
- /how-tos/train-deploy-ml/
- /services/ml/
+ - /registry/ml/
+ - /services/ml/upload-model/
+ - /services/ml/edit/
+ - /ml/edit/
+ - /manage/data/upload-model/
+ - /manage/ml/upload-model/
+ - /ml/upload-model/
+ - /services/ml/ml-models/
---
The Machine Learning (ML) model service allows you to deploy [machine learning models](/data-ai/ai/deploy/#deploy-your-ml-model) to your machine.
@@ -66,5 +74,5 @@ For other use cases, consider [creating custom functionality with a module](/ope
{{< alert title="Add support for other models" color="tip" >}}
ML models must be designed in particular shapes to work with the `mlmodel` [classification](/operate/reference/services/vision/mlmodel/) or [detection](/operate/reference/services/vision/mlmodel/) model of Viam's [vision service](/operate/reference/services/vision/).
-See [ML Model Design](/registry/advanced/mlmodel-design/) to design a modular ML model service with models that work with vision.
+See [ML Model Design](/operate/reference/advanced-modules/mlmodel-design/) to design a modular ML model service with models that work with vision.
{{< /alert >}}
diff --git a/docs/dev/reference/glossary/part.md b/docs/dev/reference/glossary/part.md
index d8d6c73332..489facb829 100644
--- a/docs/dev/reference/glossary/part.md
+++ b/docs/dev/reference/glossary/part.md
@@ -1,7 +1,7 @@
---
title: Part
id: part
-full_link: /architecture/parts/
+full_link: /operate/reference/architecture/parts/
short_description: A single-board computer, desktop, laptop, or other computer running viam-server, the hardware components attached to it, and any services or other resources running on it.
---
diff --git a/docs/dev/reference/glossary/resource.md b/docs/dev/reference/glossary/resource.md
index 64908efa2f..1406db8a2e 100644
--- a/docs/dev/reference/glossary/resource.md
+++ b/docs/dev/reference/glossary/resource.md
@@ -17,4 +17,4 @@ Resources are individual, addressable elements of a machine.
Each part has local resources and can also have resources from another {{< glossary_tooltip term_id="remote-part" text="remote">}} machine part.
The capabilities of each resource are exposed through the part’s API.
-Each resource on your machine implements either one of the [existing Viam APIs](/dev/reference/apis/), or a [custom interface](/registry/advanced/#new-api-subtypes).
+Each resource on your machine implements either one of the [existing Viam APIs](/dev/reference/apis/), or a [custom interface](/operate/reference/advanced-modules/#new-api-subtypes).
diff --git a/docs/dev/reference/sdks/use-extra-params.md b/docs/dev/reference/sdks/use-extra-params.md
index 522bbfa21c..7442384e89 100644
--- a/docs/dev/reference/sdks/use-extra-params.md
+++ b/docs/dev/reference/sdks/use-extra-params.md
@@ -90,7 +90,7 @@ If passing an object of type `nil`, you must specify `nil` in the method call or
## Define
-If `extra` information must be passed to a resource, it is handled within a new, _modular_ resource model's [custom API](/registry/) wrapper.
+If `extra` information must be passed to a resource, it is handled within a new, _modular_ resource model's [custom API](/operate/get-started/other-hardware/) wrapper.
{{%expand "Click for instructions on defining a custom model to use extra params" %}}
diff --git a/docs/operate/get-started/other-hardware/cpp-module.md b/docs/operate/get-started/other-hardware/cpp-module.md
index a9dbab0724..60afd3f6f7 100644
--- a/docs/operate/get-started/other-hardware/cpp-module.md
+++ b/docs/operate/get-started/other-hardware/cpp-module.md
@@ -70,7 +70,7 @@ If you want to write a module to add support to a new type of component or servi
- 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](/registry/advanced/create-subtype/), but this is even more advanced than using `generic`.
+- 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 %}}
diff --git a/docs/operate/reference/advanced-modules/_index.md b/docs/operate/reference/advanced-modules/_index.md
new file mode 100644
index 0000000000..7cb6059986
--- /dev/null
+++ b/docs/operate/reference/advanced-modules/_index.md
@@ -0,0 +1,53 @@
+---
+title: "Advanced Modular Resources"
+linkTitle: "Advanced Modules"
+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 using a server on a remote part"
+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 API subtype, 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 API subtypes
+
+The [component APIs](/dev/reference/apis/#component-apis) and [service APIs](/dev/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](/dev/reference/sdks/use-extra-params/) to add custom functionality to an existing resource {{< glossary_tooltip term_id="subtype" text="subtype" >}}.
+
+Or, if your resource does not fit into an existing resource subtype, 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](/dev/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](/dev/reference/apis/#service-apis), you can use the [generic service](/dev/reference/apis/services/generic/) to build your own service API.
+
+Both generic resources use the [`DoCommand`](/dev/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 subtype and an API for that subtype](/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.
+
+## Design a custom ML model
+
+When working with the [ML model service](/dev/reference/apis/services/ml/), you can deploy an [existing model](/data-ai/ai/deploy/) or [train your own model](/data-ai/ai/train/).
+
+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](/dev/reference/apis/services/vision/), you can also [design your own ML model](/operate/reference/advanced-modules/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
new file mode 100644
index 0000000000..b2e468da4f
--- /dev/null
+++ b/docs/operate/reference/advanced-modules/create-subtype.md
@@ -0,0 +1,107 @@
+---
+title: "Define a New Resource Subtype"
+linkTitle: "New API Subtype"
+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 subtypes."
+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" >}} _{{< glossary_tooltip term_id="subtype" text="subtype" >}}_ 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" >}} subtypes.
+- You have a resource that could fit into an existing subtype, but you want to define an API with different methods and messages than the ones in the existing [APIs](/dev/reference/apis/) for that subtype.
+
+{{% alert title="Tip" color="tip" %}}
+
+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](/dev/reference/sdks/use-extra-params/) to add custom functionality to an existing subtype.
+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 subtype, you need to define the methods and messages of the new 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 subtype 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 subtype.
+ For example, `gizmo`.
+
+ Determine a valid {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet" >}} based on your subtype 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/get-started/other-hardware/).
+
+ {{< expand "API namespace triplet and model namespace triplet example" >}}
+
+ The `viam-labs:audioout:pygame` model uses the repository 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 in the Viam app.
+
+ {{< /expand >}}
+
+1. Create a directory for your module.
+ Within that, create a directory called src.
+
+ {{% 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 `.proto` file inside your src/proto 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.
+
+ - [buf.yaml](https://buf.build/docs/configuration/v1/buf-gen-yaml/)
+ - [buf.gen.yaml](https://buf.build/docs/configuration/v1/buf-gen-yaml/)
+ - [buf.lock](https://buf.build/docs/configuration/v1/buf-lock/)
+
+1. In the /src/ 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 `.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 speech.proto was manually written.
+
+## Next steps
+
+{{< cards >}}
+{{% manualcard link="/operate/get-started/other-hardware/" %}}
+
+Implement your API
+
+Now that your resource API is defined, create a new model that implements your new API.
+
+{{% /manualcard %}}
+{{< /cards >}}
diff --git a/docs/operate/reference/advanced-modules/custom-components-remotes.md b/docs/operate/reference/advanced-modules/custom-components-remotes.md
new file mode 100644
index 0000000000..561eff6f69
--- /dev/null
+++ b/docs/operate/reference/advanced-modules/custom-components-remotes.md
@@ -0,0 +1,72 @@
+---
+title: "Add Custom Components as Remote Machine 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/get-started/other-hardware/) because you need to host `viam-server` on a non-Linux system or have an issue with compilation, you can use a [Viam SDK](/dev/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](/dev/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](/dev/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) [Configure a process](/manage/reference/processes/) to launch this remote server to ensure the remote server is always running alongside the rest of your machine.
+
+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](/dev/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) [Configure a process](/manage/reference/processes/) to launch this remote server to ensure the remote server is always running alongside the rest of your machine.
+
+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/mlmodel-design.md b/docs/operate/reference/advanced-modules/mlmodel-design.md
new file mode 100644
index 0000000000..9bf5d62446
--- /dev/null
+++ b/docs/operate/reference/advanced-modules/mlmodel-design.md
@@ -0,0 +1,128 @@
+---
+title: "Design your ML Models for Vision"
+linkTitle: "ML Model Design"
+weight: 60
+type: "docs"
+tags: ["data management", "ml", "model training", "vision"]
+description: "Design your ML Model service to work with Viam's vision services."
+icon: true
+images: ["/services/icons/ml.svg"]
+date: "2022-01-01"
+# updated: "" # When the content was last entirely checked
+# SME: Bijan Haney
+aliases:
+ - /registry/advanced/mlmodel-design/
+---
+
+The [Machine Learning (ML) model service](/data-ai/ai/deploy/) allow you to deploy machine learning models to your smart machine.
+Vision services, like [an `"mlmodel"` detector](/dev/reference/apis/services/vision/#detections) or [classifier](/dev/reference/apis/services/vision/#classifications), enable your machines to identify and classify objects in images with the deployed models' predictions.
+
+The two services work closely together, with the vision service relying on the deployed ML model to make inferences.
+If you are [designing your own ML Model service](/data-ai/ai/deploy/), you must try to make your ML models' shapes match the input and output tensors the `mlmodel` vision service expects to work with if you want the two services to coordinate in classification or detection.
+
+To be able to use a deployed ML model, the `mlmodel` vision service checks for descriptions of these characteristics in the [metadata](/dev/reference/apis/services/ml/#metadata) of the model, as defined in [the Python SDK](https://python.viam.dev/autoapi/viam/gen/service/mlmodel/v1/mlmodel_pb2/index.html#viam.gen.service.mlmodel.v1.mlmodel_pb2.Metadata).
+For an example of this, see [Example Metadata](#example-metadata).
+
+## Input tensor: `input_info` in metadata
+
+For both [classification](/dev/reference/apis/services/vision/#classifications) and [detection](/dev/reference/apis/services/vision/#detections) models, the vision service sends a single input tensor to the ML Model with the following structure:
+
+- One input tensor called `"image"` with type `uint8` or `float32` and shape `(1, height, width, 3)`, with the last channel `3` being the RGB bytes of the pixel.
+- If image `height` and `width` are unknown or variable, then `height` and/or `width` `= -1`. During inference runtime the image will have a known height and width.
+
+## Output tensors: `output_info` in metadata
+
+Data can be returned by the ML model in many ways, due to the variety of machine learning models for computer vision.
+The vision service will try to take into account many different forms of models as specified by the metadata of the model.
+If the model does not provide metadata, the vision service will make the following assumptions:
+
+For [classifications](/dev/reference/apis/services/vision/#classifications):
+
+- The model returns 1 tensor, called `"probability"` with shape `(1, n_classifications)`
+- The data is floating point numbers representing probability, between `0` and `1`.
+- If the data is not between `0` and `1`, the vision service computes a softmax over the data, resulting in floating point numbers between `0` and `1` representing probability.
+
+For [detections](/dev/reference/apis/services/vision/#detections):
+
+- The model returns 3 tensors
+ 1. `"Location"`: the bounding boxes
+ - Shape: `(1, n_detections, 4)`
+ - Bounding boxes each have shape `(xmin, ymin, xmax, ymax)`
+ - Bounding boxes are the proportion of where the box corner is in the image, using a number between `0` and `1`.
+ 2. `"Category"`: the labels on the boxes
+ - Shape: `(1, n_detections)`
+ - Integers representing the index of the label.
+ 3. `"Score"`: The confidence scores of the label
+ - Shape: `(1, n_detections)`
+ - Floating point numbers representing probability, between `0` and `1`.
+
+For labels:
+
+- Many computer vision models have an associated 'labelfile.txt' that lists the class labels associated with the model.
+ To get those labels associated with the model, currently the vision service looks at the first element of the `output_info` list in the ML models' metadata and checks for a key called `"labels"` in its `"extra"` struct.
+ The value of that key should be the full path to the label file on the machine.
+ See [Example Metadata](#example-metadata) for an example of this.
+
+ ```sh {class="command-line" data-prompt="$"}
+ label_path = ml_model_metadata.output_info.extra["labels"]
+ ```
+
+### Example metadata
+
+For example, a TF lite detector model that works with the vision service is structured with the following [metadata](/dev/reference/apis/services/ml/#metadata):
+
+```json {class="line-numbers linkable-line-numbers"}
+name: "EfficientDet Lite0 V1"
+type: "tflite_detector"
+description: "Identify which of a known set of objects might be present and provide information about their positions within the given image or a video stream."
+input_info {
+ name: "image"
+ description: "Input image to be detected. The expected image is 320 x 320, with three channels (red, blue, and green) per pixel. Each value in the tensor is a single byte between 0 and 255."
+ data_type: "uint8"
+ shape: 1
+ shape: 320
+ shape: 320
+ shape: 3
+ extra {
+ }
+}
+output_info {
+ name: "location"
+ description: "The locations of the detected boxes."
+ data_type: "float32"
+ extra {
+ fields {
+ key: "labels"
+ value {
+ string_value: "/Users//.viam/packages/.data/ml_model/effdet0-1685040512967/effdetlabels.txt"
+ }
+ }
+ }
+}
+output_info {
+ name: "category"
+ description: "The categories of the detected boxes."
+ data_type: "float32"
+ associated_files {
+ name: "labelmap.txt"
+ description: "Label of objects that this model can recognize."
+ label_type: LABEL_TYPE_TENSOR_VALUE
+ }
+ extra {
+ }
+}
+output_info {
+ name: "score"
+ description: "The scores of the detected boxes."
+ data_type: "float32"
+ extra {
+ }
+}
+output_info {
+ name: "number of detections"
+ description: "The number of the detected boxes."
+ data_type: "float32"
+ extra {
+ }
+}
+```
diff --git a/docs/operate/reference/module-configuration.md b/docs/operate/reference/module-configuration.md
index 8b1ff7a2d8..28b4c2e841 100644
--- a/docs/operate/reference/module-configuration.md
+++ b/docs/operate/reference/module-configuration.md
@@ -77,7 +77,7 @@ The following properties are available for modular resources:
| ---- | ---- | --------- | ----------- |
| `attributes` | object | Sometimes **Required** | Any configuration attributes for your model Check the module's GitHub Readme for information about available configuration attributes for a resource. |
| `name` | string | **Required** | What you want to name this instance of your modular resource. |
-| `namespace` | string | **Required** | The namespace of the API (the first part of the {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet">}}). This will be `rdk` unless the module implements a [custom, non-standard API](/registry/advanced/). |
+| `namespace` | string | **Required** | The namespace of the API (the first part of the {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet">}}). This will be `rdk` unless the module implements a [custom, non-standard API](/operate/reference/advanced-modules/). |
| `type` | string | **Required** | The {{< glossary_tooltip term_id="subtype" text="subtype">}} of the API (the third part of the {{< glossary_tooltip term_id="api-namespace-triplet" text="API namespace triplet">}}). |
| `model` | string | **Required** | The full {{< glossary_tooltip term_id="model-namespace-triplet" text="model namespace triplet">}} of the modular resource's {{< glossary_tooltip term_id="model" text="model" >}}. |
| `depends_on` | array | Optional | The `name` of components you want to confirm are available on your machine alongside your modular resource. Often a [board](/operate/reference/components/board/). Unnecessary if you coded [implicit dependencies](/operate/reference/viam-server/#dependency-management). |
diff --git a/docs/operate/reference/services/slam/cloudslam/_index.md b/docs/operate/reference/services/slam/cloudslam/_index.md
index 4af4920abf..f03b37b512 100644
--- a/docs/operate/reference/services/slam/cloudslam/_index.md
+++ b/docs/operate/reference/services/slam/cloudslam/_index.md
@@ -431,7 +431,7 @@ The following attributes are available for `viam:cloudslam-wrapper: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](/dev/reference/glossary/#organization). |
-| `location_id` | string | **Required** | The location ID of your [location](/dev/reference/glossary/#location/). |
+| `location_id` | string | **Required** | The location ID of your [location](/dev/reference/glossary/#location). |
| `machine_id` | string | **Required** | The machine ID of your [machine](/dev/reference/apis/fleet/#find-machine-id). |
| `machine_part_id` | string | Optional | The machine part ID of your [machine part](/dev/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`. |