"update your code" is a good example. Maybe "init" is unnecessary, since the robot could automatically initialize itself on startup before looking for orders. Similarly, instead of creating a "stop" order, you could cancel or delete any existing orders, and the robot will stop when it has no active orders.
The details of the API will depend greatly on your use case. Ideally, an order will be self-contained, so that a robot that receives it can carry out the order even if it loses network connectivity partway through. For example, I've tried to adapt the example from the tutorial to reflect your suggestions:
apiVersion: example.com/v1
kind: Order
metadata:
name: my-move-order
spec:
moveItem:
from: manufacturing
to: logistics
destinationAfterMove: waitingArea
or
apiVersion: example.com/v1
kind: Order
metadata:
name: my-update-order
spec:
installUpdate:
url: https://myproject.com/updates/2020-03-10.tar.gz
For a real-world example, you can look at the ewm-cloud-robotics project:
- API definition: mission-crd.yaml
- API client: robco_mission_api.py
- API implementation: mission.py
I feel I should give a caveat: a declarative API might be overkill if you have good network connectivity, in which case you may prefer to use a VPN and ROS2 actionlib. Also, if you think your API will be too complicated for metacontroller, and you want to use a programming language other than Python or Go then you should consider storing your orders in a database like Redis or MySQL, instead of using the Kubernetes apiserver (last I checked, there wasn't good client support for languages other than Python or Go).
Excellent response Rodrigo Queiro, thank you very much. Now, i don't know if the declarative API would be exaggerated for my use case, but following that example of updating the code: The part that I don't fully understand (excuse my ignorance) is how will the robot receive those orders? A response to an HTTP query as in the example of the cloud simple service? (googlecloudrobotics.github.io/core/how-to/… ) So that the answer can be processed in Python, or how would it be in this case?
The difference in a declarative API is that instead of "one HTTP query per order", with the response coming as an HTTP response, we have "one resource per order", where the resource is an entry in a database. The resource specification (spec) is like the request, and the status is the response, which will be repeatedly updated. More info: metacontroller.app/concepts kubernetes.io/docs/concepts/overview/working-with-objects/…
Thank you very much Rodrigo Queiro, now I have a little more clarity regarding the issue. I will read the documentation you left.
How should server.py be written to work with "update your code"? A basic model.
I haven't tried implementing remote updates, so I can't be confident, but I can imagine a procedure like: 1) check for "update" orders, 2) set update_order.status=IN_PROGRESS, 3) download & verify update file, 4) install update, 5) set update_order.status=INSTALLED 6) restart system, 7) check for "update" orders and find order.status=INSTALLED, 8) perform post-update test, 9) set update_order.status=COMPLETE, 10) wait for new orders.