A DSL for high level robotic tasks

The purpose of any Domain Specific Language (DSL) is to make your life easier when working in a specific domain. Robotic languages are no exception. Each of them is already a DSL specific for the given robot vendor. They simplify your life with high level move and IO instructions for example. What they allow you to do is express your intent, not the details behind it. You state what needs to be done, not how it should be done.

If you take this idea a little further and implement it on a layer above the robotic languages you can do the same for other types of common robotic tasks. Pick & place, bin picking, pattern picking, palletizing etc. Think of these as higher order instructions that can be implemented using the robotic languages but are not natively supported by them. I imagine this higher order DSL as a universal robotic language that you can use for these more complex use cases. I can imagine more useful statements like: fasten a screw, polish a surface, insert a peg into a hole etc. It could even be quite human readable...

Like any other language, the statements that you write can be easily combined in an even more complex use case.

I am not aware of anything like this that currently exists.

How can this language be developed?

In essence this is the task of translating from one language to another. This is what source-to-source compilers (a.k.a. transpilers) do. The transpiler builds an abstracts syntax tree (AST) as an intermediate representation (IR) of the program code written in the source language. Then it generates the program code in the target language based on that AST. Sounds simple but in reality it is quite difficult to do. You need deep understanding of the source and target languages. Furthermore with this approach you'll need several transpilers. One for each target language.

If we leave the complexity aside, this DSL will enable UIs to be built on top of it. Building blocks similar to function blocks in SCL can be dragged & dropped to create robotic programs.

Ask ChatGPT to "create a list common robotic tasks". It is quite a list but these could be the instructions in our new language. We'll have to define the grammar for it. ANTLR will provide the parser and the parse tree. Then we have to build the AST and the first part is done.

The second part is more difficult. Translating to the target language is the real problem. Not because of the syntax but because the workflow should be defined first. It should be generic enough to be reused. Resource (variables, registers etc.) sharing is a problem. Sometimes the target language can be limited in a way that prevents us from achieving the goal. Error reporting can be problematic. There are a ton of problems to solve before you reach there.

ChatGPT can explain how this language translation is supposed to work. Also it explains why it is currently non-existent. Also it says that this is the best option that might work really well.

I agree with all the facts that it throws at me.

Here is what it says when asked this: "which is better to have a DSL or a UI for robotic operations?"

>>>

Short answer: neither is universally “better.”

The right choice depends on who is expressing intent, how often tasks change, and how complex the logic is. In practice, the best systems almost always use both.

The Core Tradeoff

Question	DSL (Domain-Specific Language)	UI (Graphical / No-Code)
Who uses it?	Engineers, power users	Operators, technicians
Expressiveness	Very high	Medium
Scalability	Excellent	Limited by UI complexity
Version control	Native (text)	Poor or indirect
Automation	Excellent	Limited
Learning curve	Steep	Shallow
Debugging	Precise	Visual but coarse
Long-term maintenance	Strong	Can degrade

When a DSL is Better

Choose a DSL if:

• Tasks involve complex logic

• You need branching, loops, constraints, recovery

• You want version control, testing, CI

• Tasks are generated automatically (planner, LLM, optimizer)

• You expect many variants of similar tasks

DSL strengths

• Express intent precisely

• Compact representation of complex behavior

• Easy to diff, review, and validate

• Ideal for planners, behavior trees, PDDL, skill orchestration

DSL weaknesses

• Not accessible to non-programmers

• Harder to discover capabilities

• Requires tooling (editors, validators)

When a UI is Better

Choose a UI if:

• Users are non-programmers

• Tasks are repetitive and local

• You want fast setup and training

• Safety and validation must be highly constrained

• Robot tasks are predefined skills

UI strengths

• Discoverability (“what can the robot do?”)

• Lower error rate

• Faster onboarding

• Visual debugging

• Safer by construction

UI weaknesses

• Poor scalability for complex logic

• Hard to express abstraction

• Difficult to diff or version

• Can become brittle as complexity grows

Why the Best Systems Use Both

Key insight

The DSL is the source of truth.The UI is a projection of the DSL.

Examples:

• UI generates DSL code

• DSL drives UI visualization

• Experts edit DSL directly

• Operators never see it

Recommended Architecture (Best Practice)

1. Define a minimal task DSL

   • Goals

   • Skills

   • Preconditions

   • Failure handling

2. Build a constrained UI on top

   • Task graphs

   • Parameter panels

   • Validation rules

3. Never put logic only in the UI

   • UI should emit DSL

   • Executor only reads DSL

A Rule of Thumb

If a task can’t be reasonably expressed in 10–20 lines of text, a UI will eventually become unmanageable.

<<<

This fully reflects my understanding.

We should base our UIs on a DSL. The DSL is mandatory to have for these complex use cases where UIs become unmanageable.

This what I try to do with SCL as well.

So cheers!

We finally have our answer!

The DSL is the way to go!