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`. |