KINOVA
®
Gen3 Ultra lightweight robot
User Guide
125
• set a nested object
• get/set a collection
For more details on how the above works, check out the following documentation on the
Google Protocol Buffer website:
• C++ tutorial:
https://developers.google.com/protocol-buffers/docs/reference/cpp-generated
• Python tutorial:
https://developers.google.com/protocol-buffers/docs/reference/python-
generated
Service client-server model
This section describes the client-server model for services.
Services operate on a
client-server
model. The
server
component of the service runs on the
device itself. The
client
component runs on the client computer.
Services offer a set of device functionalities which are transparently exposed to the end-user via
RPC and pub/sub methods.
The API is built on a transparent client/server communication protocol which allows an end-
user (client side) to call methods on robot devices.
Notifications
This section describes the concept of notifications in the API.
The robot base can provide notifications on different topics as requested by a client application
that has a session open with the robot.
The robot base uses a Publish/Subscribe design pattern. That is, rather than needing to poll
periodically for updates, the client application subscribes to a list of Topics. Whenever a change
happens related to that topic, whether caused by the same client session, or another, a publisher
sends a notification to all subscribers. Notifications are surfaced to clients via the API, and are
also displayed in the Notifications page of the Web app.
Client applications can also unsubcribe from a topic.
Methods for subscribing and unsubscribing from notification topics are descrcibed in the API
documentation on the KINOVA
®
KORTEX™ GitHub respository.
Blocking and non-blocking calls
This section describes the concept of blocking vs. non-blocking calls in the context of RPCs
on the robot.
The API defines interfaces of methods to be executed on devices in the robot.
The methods can be one of two types, depending on what the client application does while
waiting for the response:
• blocking
• non-blocking
With a blocking call, the flow of the client application will pause and wait for the remote
procedure call to return a response before proceeding. With non-blocking call, the procedure
call is sent, and the flow of the application carries on while waiting for the response. When the
response arrives, the caller will handle the response.
For the Python API, only blocking calls are enabled.
In the context of C++, remote procedure calls in the API can in general be set as either
blocking
or
non-blocking
.
