Develop an app on top of Wandelbots NOVA
Once you've mastered robot programming and have created programs you want to share, manage, or integrate into larger systems, you can develop custom applications on Wandelbots NOVA.
App development on Wandelbots NOVA showcases its powerful capabilities when you want to:
- Create custom UIs for your robot programs
- Distribute your robot programs to other users
- Integrate robot control into existing business systems
- Use custom hardware devices alongside your robots
Development approaches
Wandelbots NOVA offers different development approaches that provide flexible options for building applications.
Python standalone
Write robot programs directly using the NOVA Python SDK with decorators and classes.
More information can be found in the Readme to the Python SDK (opens in a new tab) or by exploring the Python SDK GitHub repository (opens in a new tab).
Multi-language web applications
Build modern web applications by creating a Python backend with any frontend technology.
- Python backend: Use the NOVAx framework (opens in a new tab) to create FastAPI servers that expose robot programs as REST APIs.
- Any frontend: TypeScript, React, Vue, Angular, or any other frontend technology can consume the REST API endpoints.
TypeScript
You can also use the Wandelbots NOVA TypeScript SDK to build web applications. To follow this approach, explore the following resources:
- Wandelbots NOVA CLI documentation (opens in a new tab)
- Wandelbots NOVA TypeScript SDK documentation (opens in a new tab)
- Wandelbots NOVA templates for TypeScript applications (opens in a new tab), which can be created using the Wandelbots NOVA CLI.
Built-in web interfaces
FastAPI automatically provides interactive documentation and testing interfaces at /docs
for immediate use.
Robot programming languages
Wandelbots NOVA supports multiple programming languages for robot applications:
- Python: All robot control logic uses the NOVA Python SDK with
@nova.program
decorators. - Wandelscript: Domain-specific language for robot programming, integrated through the SDK.
Choose your development approach based on your needs, whether it's a standalone Python program, a web application with a Python backend, or a built-in web interface.
Legally required elements
When developing a robotic application, there are certain app elements that are common or even legally required. To support you in your development process, we've collected a set of common standards and legal requirements for robotic applications. Some of these elements are available in our storybook components (opens in a new tab).
Robot safety state and operating mode
A robotic app must visibly provide information on the robot's status, operating mode and errors at all times.
Standard | Example |
---|---|
DIN EN ISO 10218-1 | In the Wandelbots NOVA core app Robot Pad these standards are fulfilled by the status bar on the top of the screen. |
Operating modes must follow a standardized icon list.
Robot control
It must always be made clear by the UI which device is currently controlling the robot.
Standard | Example |
---|---|
DIN EN ISO 10218-1 | Status field in the UI |
Standard | Example |
---|---|
ISO 7000 | Automatic and manual modes have standardized symbols. |
Singularity
If a robot has reached or will reach a singularity on a planned path, the user must be informed.
Standard | Example |
---|---|
DIN EN ISO 10218-1 | Popups |
Switching between devices
Switching between control devices must be an active decision made by the user.
Standard | Example |
---|---|
DIN EN ISO 60204 | via a button in the UI |
Activation
Activating a robot can never be done automatically. It must be an active decision made by the user.
Standard | Example |
---|---|
DIN EN ISO 10218-1 | via a button in the UI |
Velocity
The robot's TCP velocity must be adjustable.
Standard | Example |
---|---|
DIN EN ISO 10218-1 | via a slider in the UI |
Authentication
Technical components must have limited access for unauthorized users.
Standard | Example |
---|---|
DIN EN ISO 60204 | Login credentials |
Emergency stop
Resetting an emergency stop must be an active decision made by the user. Never reset an emergency stop automatically.
Standard | Example |
---|---|
ISO 13850:2015 | manual action |
Resets of emergency stops can't result in machine reboots, actions or movements.
Standard | Example |
---|---|
ISO 13850:2015 | Interrupted movements have to be restarted after an e-stop has been triggered. |
Communication losses
Communication losses between components must result in a safety stop.
Standard | Example |
---|---|
DIN EN ISO 10218-1 | The ethernet connection gets lost and the robot immediately stops moving. |
Restored communication can't result in machine reboots, actions or movements.
Standard | Example |
---|---|
DIN EN ISO 10218-1 | Interrupted movements have to be restarted after a connection loss. |
Documentation
Robotic applications may fall under the EU Machinery Directive and EU Machinery Regulation. This Directive/Regulation also regulates the technical documentation including risk assessments, user instructions and UI texts. They also determine whether recertification of a machine is required after adding software to it. We strongly recommend consulting with a legal expert to ensure compliance with these regulations.