Design Decisions

Why OctoMY™ is built the way it is

Design Decisions

The key design decisions that shape OctoMY™ and the reasoning behind them.

Did You Know?

The decision to use Qt was made partly because of its excellent cross-platform support, but also because Qt was one of the few frameworks that could deploy to Android phones while still providing native C++ performance for real-time robotics. This lets you use your old Android phone as a robot brain.


Core design philosophy

OctoMY™ is built around five principles:

Complete

The solution should stand on its own and provide a complete feature set that gives value to most hobby-class robot projects. Rather than being a collection of disconnected tools, OctoMY™ aims to be a unified platform.

Nimble

Provide the important bits but avoid pulling in unnecessary dependencies. Add only nimble and useful features. Reap benefits of code reuse and simplicity by sticking to one platform - Qt can be deployed to Android/iOS devices, Windows/macOS, and Linux desktops.

Cutting edge

Harness the power of modern concepts in robotics, including deep learning and advanced sensor fusion.

Robust

Always provide a stable version. Follow good practices for maintaining the software in a stable state. Users should be able to rely on OctoMY™.

Social

Provide a vessel for learning about advanced robotics topics for anyone involved. The project should be educational as well as practical.


Platform choice: Qt

OctoMY™ uses the Qt framework exclusively. This decision was made for several reasons:

  • Cross-platform - Single codebase deploys to desktop (Linux, Windows, macOS) and mobile (Android, iOS)
  • Mature ecosystem - Decades of development, comprehensive documentation
  • Native performance - C++ foundation provides excellent performance for real-time robotics
  • Rich widget toolkit - Building complex UIs is straightforward
  • Networking built-in - Qt provides robust networking primitives

Architecture: Distributed peer-to-peer

OctoMY™ operates as a distributed system where nodes communicate directly:

  • No central server required - Nodes can discover and communicate with each other directly
  • End-to-end encryption - Security is built in from the start
  • Graceful degradation - System continues working despite network issues
  • Privacy by design - Users control their own data

Communication: Custom protocol

Rather than using HTTP or standard protocols, OctoMY™ uses a custom UDP-based protocol:

  • Optimized for real-time - Low latency for robot control
  • Bandwidth efficient - Minimal overhead for constrained networks
  • NAT traversal - Works across network boundaries
  • Reliable when needed - Built-in reliability for important messages

Trust model: Graduated trust

OctoMY™ implements a graduated trust model rather than binary authentication:

  • Multiple trust levels - From completely blocked to fully trusted
  • Operator control - Humans decide trust levels, not algorithms
  • Auditable - All trust decisions are logged
  • Revocable - Trust can be withdrawn at any time

Behavior system: Plans

Robot behavior is defined through Plans (formerly called Dogma):

  • Declarative - Describe what should happen, not how
  • Portable - Plans can be shared between robots
  • Safe - Plans are validated before execution
  • Extensible - New commands can be added

The integration problem

While there are hundreds of robotics projects implementing individual features, no ecosystem exists that allows them to coexist on a single robot in a robust, performant, and user-friendly manner.

OctoMY™ addresses this by:

  1. Making good architectural decisions from the start
  2. Creating a standard of quality
  3. Implementing features one by one within a unified platform
  4. Building a community that can contribute under a single umbrella

In this section
Topics
explanation philosophy design architecture Qt
See also