< All Topics

NEPI Engine – Automation Management System


This document describes NEPI’s Automation Script Management (ASM) system as well as automation script file content and structure. The ASM system provides both programmatic and an intuitive no-code interface for loading, running, and orchestrating automation scripts from a NEPI device’s onboard automation script library. The ASM system also supports automation script output logging for quickly resolving issues with automation script execution.

NOTE: This document is intended for developers wanting to create, modify, and manage custom automation scripts. For individuals just looking for information on installing and running automation scripts on there system using NEPI’s RUI Automation application, see the NEPI Engine Automation application tutorial at:


NEPI ASM System Overview

The ASM system works with a variety of scripting languages by applying the appropriate process framework (e.i. shell scripts, python scripts…) stored in an on-board library of installed automation scripts. For ASM python scripts that use the python rospy module to interact with either NEPI’s or a locally connected ROS environment, the ASM system creates custom ROS nodes when launching the scripts. The AIS system manages automation script startup and based on a configuration file, as well as in-situ startup and stopping through set of ROS services as illustrated the figure below.

A diagram of a software script management system Description automatically generated


The NEPI ASM ROS node is an application for orchestrating (starting, monitoring, logging, and stopping) automation scripts stored in a NEPI device’s automation script library.

When starting an automation script, the ASM system properly selects and runs the script with the proper ASM process framework. Two commonly used process frameworks are the operating system’s shell command-line interpreter (CLI) and the operating system’s python interpreter. Additional script process frameworks like MATLAB could be added to the ASM’s process framework system.

NOTE: The ASM system runs scripts in the OS’s user environment, so any file level access or changes performed in a script must be executable by the user and not require root level permissions. In some cases, it may be necessary to change NEPI File System file and/or folder permissions to allow scripts to access and modify file system components.

NEPI ASM Process Frameworks
Driver Class NameDescription
Shell CLIThe operating system’s shell command-line interface (CLI) and interpreter
Python3The operating system’s python script interpreter

The ASM ROS node provides ROS service calls for requesting a list of available automation scripts, starting scripts, and stopping scripts. These services can be called from both external ROS processes and automation scripts running within the ASM system.    

ROS ServiceDescription
get_scriptsReturns a list of script installed in the ASM automations script library folder
get_running_scriptsReturns a list of currently running scripts
launch_scriptAccepts a script filename and starts the script if it exists
stop_scriptAccepts a script filename and stops the script if it is running

These ASM ROS automation script orchestration services are also callable from NEPI automation scripts.  For an example automation script that automates starting and stopping installed automation scripts, see the “_object_detect_and_snapshot_startup_script.py” script available at:


If you need to add additional ASM process frameworks to your NEPI device, you can access and edit the ASM ROS Node source-code located in the NEPI File System folder:

  1. /home/nepi/nepi_base_ws/src/nepi_automation_mgr/

NOTE: See the NEPI Engine tutorial NEPI File System Customizing for more information on customizing and compiling NEPI ROS node changes at:


ASM Automation Script Library

The ASM ROS node constantly monitors the ASM Automation Script Library for changes and updates its internal script database. The ASM Automation Script Library is located on the user storage drive mounted in the NEPI File System at:


This folder is also accessible and editable from a PC’s File Manager application connected to the NEPI user storage drive at:

On Linux PCs


On Windows PCs


NOTE: Scripts deployed into the ASM’s Automation Script Library must be supported by one of the ASM’s process frameworks installed on your NEPI device. In addition, any script dependencies must be either preinstalled on your NEPI device’s file system, or explicitly called from a location on the NEPI user storage drive.

ASM Config Files

The ASM leverages a configuration file that stores a list of scripts that should be started automatically after the NEPI device completes its boot process on power up. Scripts can be added to this auto-start config file using the ROS topic “enable_script_autostart”, or by selecting the script in the NEPI Device’s RUI and clicking the “Auto Start” selector switch.

ASM Script Input Streams

Automation scripts running in the ASM system can access any ROS topic currently being published within the NEPI ROS environment, including data being published by other running automation scripts, or by an external ROS node on a connected network.

ASM Output Topics

Automation scripts running in the ASM system can publish ROS messages to current available ROS topics available in the NEPI ROS environment or create and publish new custom topics.

ASM Process Logging

The ASM system creates log files for each script that is launched, then saves automation framework error messages and script print statement messages to those files. Automation script log files are located on the NEPI device’s user storage drive under the logs folder in an automation script logs subfolder.  You can open any of the script logs to see the latest updates saved for that script. 

1) Open a file manager to your NEPI device’s automation_script_logs folder located on your NEPI device’s user storage drive at: \\\nepi_storage\logs\automation_script_logs

2) You should see logs for each of the scripts you have running, or have run since deleting the log files in this folder. Right click on any script log you want to inspect and open with a text or code editor of your choice.

NOTE: Log files are continuously updated for running scripts, so either close and reopen the file to see the latest information, or use a text editor that has auto refresh capabilities.

A screenshot of a computer Description automatically generated

A screenshot of a computer Description automatically generated

ASM Script Conventions

While the ASM system does not inspect or require any conventions on the scripts it launches, other than that they meet the requirements of the process framework the script is processed with, NEPI example scripts do follow file naming and code structure conventions to help users use and modify scripts.

NOTE: NEPI example automation scripts are available in the “nepi_sample_auto_script” GitHub repo at:


Script File Name Conventions

In order to maximize script reuse, wherever possible NEPI automation scripts should be created a primitive that can be used together to quickly create custom application solutions. In addition, script names should include a reference to their primitive function to help organize scripts within the ASM automation script library as well as help determine the proper startup sequence when launching multiple scripts for a given solution. The following table provides descriptions of NEPI example script primitive naming convention based on primitive functions.

NEPI Primitive Functions Table
startupScripts that automate starting and stopping groups of scripts for a given application or solution.
missionScripts that perform an overall mission or solution automation. Mission scripts usually depend on many other scripts running.
actionScripts that take some action based on either a direct sensor output or the output of another running script.
processScripts that take in data directly from a sensor or the output of another running script, process that data, and publish the processed for consumption by other running scripts.
configScripts that configure the NEPI system’s built in functionality. Config script may use the output data of other running scripts as part of this configuration.
driverScripts that provide driver level interfacing to attached sensors, lights, actuators, and control systems.

The general file name convention used for NEPI example automation scripts is:

<Hardware or Application Description>_<Primitive Function>_script


The NEPI example script that automates configuring AI model and a specific image input topic is named:


In addition, “startup” type scripts are proceeded with an underscore to help organize them at the top any alphabetically ordered automation script list.


The NEPI example script that automates starting a group of automation scripts to look for a specific object centered in an image and send a system wide “snapshot” event trigger is named:


ASM Script Troubleshooting

If an automation script is not launching or functioning as expected, and the ASM create script lag file does not provide enough information or you want to see feedback real-time, you can run scripts from a command line in an SSH terminal connected to your NEPI device’s file system.

NOTE: For information on creating an SSH terminal connection to your NEPI device’s file system, see the tutorial “Accessing the NEPI File System” available at: https://nepi.com/nepi-tutorials/nepi-engine-accessing-the-nepi-file-system/

1) Change directory to the NEPI Automation Script Library by typing

cd /mnt/nepi_storage/automation_scripts/

or use the built in alias


2) type the following replacing the <YourScriptName> with the full name of your script

python <YourScriptName>

NOTE: If you script requires root file system permission access, which is what the ASM system runs scripts as, change to root user in your terminal and source the NEPI ROS environment if needed before running your script.

sudo -s
source /opt/nepi/ros/setup.bash

A screen shot of a computer Description automatically generated

3) If you want to stop your script, it is important that you stop it using “Ctrl-C” to trigger a proper shutdown of the script.

A black background with white text Description automatically generated

Table of Contents