Commands of ActDK
Home / Application Development / Actcast SDK Reference Manual / Commands of ActDK

help #

actdk help subcommand shows help of actdk.

$ actdk help

It can also shows help of other subcommands.

$ actdk help <subcommand>

setup #

To initialize ActDK, use actdk setup.

$ actdk setup <TOKEN>

Use token issued on the Web UI for the <TOKEN> argument.

This command creates the .actdk directory under your home directory. For more details of .actdk, see the document of .actdk.

If your network requires proxy for external access, use actdk command with http_proxy/https_proxy environment variables.

init #

actdk init subcommand initializes a project for Actcast application.

$ actdk init -i <APP_ID> <APP_NAME>

Initialize project directory:

$ mkdir <APP_DIR>
$ cd <APP_DIR>
$ actdk init -i <APP_ID> -s <SHORT_DESCRIPTION> <APP_NAME>
  • <APP_NAME>
    • A unique identifier.
    • As app names are used as docker image names, an app name may only contain lowercase letters, digits, and separators. A separator is either a period, one or two underscores, or one or more dashes. An app name may not start or end with a separator.
  • <APP_ID>
    • An application ID.
  • <APP_DIR>
    • Name of directory you chosen.
  • <SHORT_DESCRIPTION>
    • One-line description that expresses the application.
    • Actcast Web UI displays this description for users in the list of applications.

The above command creates the following directories:

  • app
  • model
  • include
  • manifesto
  • .actdk

For more details of each directory, see ActDK Project Structure.

Reinitialization of the project #

To derive a existing project, you can use --derive option:

$ cp -a <OLD_APP_DIR> <NEW_APP_DIR>
$ cd <NEW_APP_DIR>
$ actdk init --derive -i <APP_ID> -s <SHORT_DESCRIPTION> <APP_NAME>

--derive option is suitable to create an applicaiton deriving from another appliacion because actdk init doesn’t reinitialize some files like schemas.

compile #

actdk compile subcommand compiles .nnoir file(s) under model directory and generates .so file(s). And also, it generates library’s header file(s) for C and bindings for Python.

$ actdk compile

This command generates app/libmodel.so, app/model.py and include/model.h.

For more details of compilation, see Compiler behavior.

build #

actdk build subcommand builds the Actcast applicaiton.

$ actdk build <IDENTIFIER_YOU_LIKE>
  • <IDENTIFIER_YOU_LIKE>
    • Remote device name

This subcommand builds the application on the remote devices for the test. If you want to build your application for release mode, add --release option. With this option, actdk builds your application on your host.

$ actdk build --release

Difference between ordinal builds and release builds #

The only difference between ordinal/remote build is devices to build on. The former builds applications on the remote devices and the latter on local machine. Because it takes a long time to transfer built images to the remote devices, ordinal build, which builds the application on the remote devices, serves a better development experience. Release build is suitable for testing before release as its image build cache is used for online build.

clean #

actdk clean subcommand cleans up unnecessary build artifacts from the local machine and the remote devices.

$ actdk clean

With --all option, it also removes the other images.

remote #

actdk remote is a subcommand group to manage remote devices.

add #

actdk remote add adds a new remote device under management.

$ actdk remote add <IDENTIFIER_YOU_LIKE>@<REMOTE>
  • <IDENTIFIER_YOU_LIKE>
    • Arbitrary name to identify the remote device.
  • <REMOTE>
    • Hostname or IP adderss of the device.

list #

actdk remote list subcommand lists the remote devices under management.

$ actdk remote list

del #

actdk remote del subcommand deletes a remote device from management.

$ actdk remote del <IDENTIFIER_YOU_LIKE>
  • <IDENTIFIER_YOU_LIKE>
    • The name to identify the remote device.

deploy #

actdk deploy subcommand deploys the applicaiton built with --release option to the remote device.

$ actdk deploy <IDENTIFIER_YOU_LIKE>
  • <IDENTIFIER_YOU_LIKE>
    • The name to identify the remote device.

When you check the application built with --release, you need to deploy the application to the remote device with actdk deploy.

run #

actdk run subcommand runs the application you developed on the remote device.

$ actdk run -a <IDENTIFIER_YOU_LIKE>

If you want to run your release built application, add --release option as well as in actdk build

$ actdk run -a --release <IDENTIFIER_YOU_LIKE>
  • <IDENTIFIER_YOU_LIKE>
    • The name to identify the remote device.

The command starts the application on the remote device. Without -a option, this command discards standard output of the application but the application goes on running on the remote device.

When you specify -a with actdk run, interruption by C-c stops the execution.

If there is an act_settings.json file in the current directory, the command copies the file into the remote device, and you can check that the application change the behavior with the following configuration. act_settings.json must follow the JSON schema file setting_schema.json.

With -a option, actdk checks conformance of act_logs with data_schema.json and outputs error if they don’t. You can suppress this behavior with --no-check-act-log option.

validate-json #

actdk validate-json subcommand validates act_settings.json , manifestos and the other schema files.

$ actdk validate-json

Runs just the validation that is run during actdk run.

photo #

actdk photo subcommand sends Take Photo command to the remote device.

$ actdk photo
data:image/png;base64,iVBORw0KGgoAAAANS.....QLQ+IAAAAASUVORK5CYII=

For more details of Take Photo command, see Communication between applications and the Actcast Agent.

stats #

actdk stats subcommand gets memory usages on the remote device.

$ actdk stats <IDENTIFIER_YOU_LIKE>
CPU 108.84% MEM   33.266MiB /  494.262MiB   6.730%
  • <IDENTIFIER_YOU_LIKE>
    • The name to identify the remote device.

stop #

actdk stop stops the application on the remote device.

$ actdk stop <IDENTIFIER_YOU_LIKE>
  • <IDENTIFIER_YOU_LIKE>
    • The name to identify the remote device.

upload #

actdk upload subcommand uploads and registers your built image and trained models to Actcast.

$ actdk upload

The image to upload is the release-built one.

Before uploading, you can make a file .actdk/long_description.md in the project directory, and write a full description of the application in Markdown format (see below) to that file if you upload the app’s description too.

Uploading may take a few minutes. An output like the following means the upload succeeded.

start uploading
Build ID for Raspberry Pi: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

“Build ID” is a corresponding build ID issued by Actcast.

If you want to specify the Markdown file for the full description, you can use the -d option.

$ actdk upload -d <DESCRIPTION_FILE>
  • <DESCRIPTION_FILE>
    • Path to the markdown file

Similary, you can specify the directory which contains description Markdowns in languages other than English with --long-descriptions-dir option.

$ actdk upload -d <DESCRIPTION_FILE> --long-descriptions-dir <DESCRIPTIONS_DIR>
  • <DESCRIPTIONS_DIR>
    • Path to the directories of markdown files

See ActDK Project Structure for more detail

check #

actdk check subcommand shows current status of your online builds.

$ actdk check status

This command shows the build status of the latest upload. If the command succeeds, the following output is displayed.

Succeeded at 2019-06-07 10:27:26.682066134 UTC

The lead part Succeeded represents the current build status, and its issued date follows. Actcast build has four statuses:

  • Submitted (Waiting to start build)
  • Running (Currently building)
  • Succeeded (Build succeeded)
  • Failed (Build failed)

You can also check the build status of the upload <POS> times before, where <POS> must be a number between 0 and 4.

$ actdk check status <POS>

Alternatively, you can specify a build ID directly to check the corresponding build status, like the following:

$ actdk check status <BUILD_ID>

generate #

act_settings #

actdk generate act_settings subcommand generates act_settings.json based on setting_schema.json, which is required to run actdk run.

When you run following command, you are required to input values for each properties written in setting_schema.json.Then act_settings.json is generated based on your input.

$ actdk generate act_settings

When you give --auto-fill option, input isn’t required and act_settings.json is generated automatically. In this time, values for each properties are taken from default in setting_schema.json or pre-defined values (e.g. 0, "") for each type s.

shell-completion #

actdk generate shell-completion generates completion scripts for extended shells.

Running following command loads configs for shell completion and enables it for this session.

$ source <(actdk generate shell-completion)

If you want to enable it by default, write it in .bashrc, .zshrc or like such files.

On generation, the shell you’re using is derived from SHELL environment variable. However, you can give --shell option to specify the shell. This is useful when you have launched the shell from another shell. Following shells are available as the argument:

  • bash
  • elvish
  • fish
  • powershell
  • zsh
Back to Actcast SDK Reference Manual