"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:
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).