Have you ever encountered the following challenges when developing applications on edge devices?

 

・Many libraries required to run applications are installed and management is complicated.

・Even if you want to replace the application, it is difficult to respond immediately

・Difficult to maintain version compatibility of OS, libraries, and applications

 

In order to get the most out of the NVIDIA® Jetson AGX Orin™ Developer Kit (hereafter referred to as AGX Orin), we have heard that you would like to try various applications. In that case, it is recommended to utilize “containers” and “Kubernetes”, which are representative of cloud-native technologies.

In this article, we will introduce how to experience application development using containers and Kubernetes on AGX Orin.

 

Chapter 1 Construction The system that you can experience is "robot operation by voice"

Chapter 2 Understanding the application configuration when using Kubernetes on edge devices

Chapter 3 Understand the flow of application development using containers/Kubernetes

Chapter 4 Practicing system construction using Kubernetes using Red Hat MicroShift

 

In Chapter 1, I will explain from Chapter 1 to Chapter 2. Click here for chapter 3 onwards

Chapter 1 Construction The system that you can experience is "robot operation by voice"

In this article, we aim to implement the "use case of controlling a robot with voice" shown below.

 

・Run the Riva API server on AGX Orin and recognize speech with microphone input

・According to the voice recognition result, instruct the robot to move

・Robot moves according to instructions

The robot uses SunFounder's PiCar-V, but other robots other than PiCar-V can be constructed with the same concept.

Through this use case, you can experience the following three major benefits by using containers and Kubernetes on edge devices.

Simple host OS configuration

You can keep the software configuration simple, installed directly on the OS. Therefore, OS provisioning can be easily automated.

Simplify application deployment, replacement, and update work

You can deploy, replace, and update applications remotely with one command without having to ssh login to each edge device. Rolling updates are applied to application updates, leading to the standardization of the update mechanism. Also, if you want to horizontally deploy the same system to a new edge device, you can easily reproduce it by deploying the application in the same procedure.

Simplify inter-application collaboration

You can create a highly maintainable system that minimizes the impact of adding or updating applications by loosely coupling the linkages between applications and between edge devices.

 

In addition, although not covered in this article, there is also a technology to collectively manage multiple Kubernetes even when the number of edge devices increases, so it is possible to simplify and automate operations through centralized operations.

Chapter 2 Understanding the application configuration when using Kubernetes on edge devices

When using Kubernetes on edge devices, it is important to separate hardware and usage and standardize them. In the development of applications using conventional edge devices, it was common for the application to be developed as a dedicated machine that was tied to the hardware. In addition, it has been required to deploy the minimum necessary hardware resources for the resources used by the application, and to reduce costs as much as possible to commercialize it. However, in that case, even if you want to add functions as new added value to the product, you cannot release new functions until the new product is provided. In addition, hardware and OS configurations will differ for each application, making it difficult to automate OS provisioning and configuration, creating issues that can easily lead to inefficient operations.

 

On the other hand, when using Kubernetes, it becomes an architecture that horizontally separates the OS and applications. In other words, applications are not tied to specific edge devices, and hardware can be handled generically. This makes it possible to standardize hardware and OS configurations and reduce the hurdles for automation.

However, not all applications can be horizontally separated. When drivers such as GPUs and applications need to work together, a layer of vertical integration is also created when leveraging Kubernetes.

As a basic concept, the design of the application accommodation in the edge device changes depending on whether it is "application with hardware cooperation" or "application without hardware cooperation". In the case of applications that involve hardware linkage, it is necessary to make the application resident on each edge device like a daemon. On the other hand, applications that do not involve hardware linkage should be executable on any hardware.

Next, consider the release frequency associated with the addition of functions and updates for applications with and without hardware linkage. Applications that involve hardware linkage, apart from applications such as inference applications that are vulnerable to data changes, most other applications do not update unless changes occur at the hardware level, such as data collection from PLCs and robot control. is assumed. Therefore, it can be said that the release frequency is clearly higher for applications that do not involve hardware cooperation.
There are two methods of linking between applications: request/response synchronous method and asynchronous linking via event hub.

In synchronous inter-application collaboration, a load balancer is installed at the boundary between applications so that the applications do not cooperate with each other and can be easily scaled out when the load of the application is high. On the other hand, as a method of realizing asynchronous inter-application collaboration, an "event-driven configuration" is used in which processing results and data changes of a certain application are treated as "events" and the application is executed autonomously when the event occurs. there is. An event-driven application has a component called an "event hub" that distributes events between applications, and the applications exchange events via the event hub.

Synchronous linkage methods are easy to implement and have the advantage of high real-time performance. In that case, by adopting an asynchronous linkage method, it is possible to increase the ease of change such as adding or updating functions. However, the real-time property is worse than the synchronous type.

For example, in order to reduce the difficulty of implementation in the use case targeted in this article, the following synchronous linkage method is implemented. The Riva API server, which requires a GPU, resides on AGX Orin, and the PiCar-V control program, which uses I2C for motor control, resides on the Raspberry Pi. The Riva API server performs speech recognition when receiving audio data input from the microphone. Then, based on the recognition result, driving instructions are issued to PiCar-V, and PiCar-V can be operated by voice input.

Click here for Chapter 3 Understanding the Flow of Application Development Using Containers/Kubernetes

Related product information