Advanced Modular Resources
Some use cases may require advanced considerations when designing or deploying modular resources. Depending on your needs, you may wish to define a new API subtype, deploy a custom component using a server on a remote part, or design a custom ML model.
New API subtypes
The component APIs and service APIs provide a standard interface for controlling common hardware components and higher level functionality.
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 subtype.
If your resource does not fit into any of the existing component or service subtypes or you want to define different methods for the API, you can use the generic API with DoCommand
or define a new resource subtype and an API for that subtype.
Custom components as remotes
Running modular resources on the board 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 on your machine.
Design a custom ML model
When working with the ML model service, you can deploy an existing model or train your own model.
However, if you are writing your own module that uses the ML model service together with the vision service, you can also design your own ML model to better match your specific use case.
Was this page helpful?
Glad to hear it! If you have any other feedback please let us know:
We're sorry about that. To help us improve, please tell us what we can do better:
Thank you!