Unsorted topics

This is where the author works on unfinished articles that are not yet categorized

Overarching architecture

Items

Identification

Personality

AddressBook

Plan Book

Stanza Book

Development

Construct

Triggers

Grid

Eval

Serial Config

Group

Puppet

Controller config

Actuator config

Sensor config

MediaDevice

Operations

Plan execution

Event Stream

Traxxas robot example:

Identification - id: xxxxxx - keypair: yyyyyy

Personality - name: El Traxxo - gender: male

Controllers: 1. Arduino #1 - sensors: a. imu - media: a. usb cam b. android back cam c. android front cam with depth - lobes: a. Wheeled - stanzas: a. Driving

  1. Ardumy #1
    • actuators: a. RC servo: throttle b. RC servo: steering
    • sensors: b. usb lidar
    • media: a. usb cam b. android back cam c. android front cam with depth
    • lobes: a. Wheeled

Puppet: 1. RC car - scene: - body - wheel fl - wheel fr - wheel bl - wheel br - rc servo throttle - rc servo steering - lidar - cameras

Triggers: 1. Trigger-set #1 - triggers for entering location, detecting faces, etc

Grids: 1. Grid #1 - Sensor calculations

Plan: 1. main plan: - Full autonomy - skeptron for group with 2 other agents - waypoint mission - trigger-set #1 - grid #1 - blockchain audit trails enabled

Event Stream: 1.

Agent: - Mode: - puppet: RC Car - controller: Ardumy #1

Agent modes

Authority mode

Mode Description
Independent (default) When the Agent is first commissioned, it will be in independent authority mode. This means it will just comply with local commands issuded by user in local UI.
Available When another node has been granted skeptron authority for the agent, it can only be controlled when the agent is in the available authority mode.

Skeptron mode

When a node gains skeptron authority over the agent, they may chose to control it. Given the agent is in available authority mode, the skeptron holder can enable skeptron on mode, effectively taking command of the agent.

Mode Description
Skeptron Off (default) No skeptron authority holders are currently controlling this agent.
Skeptron On A skeptron authority holder is currently controlling this agent.

Control mode

Depending on other modes, the agent can be controlled in different ways. This mode corresponds to how the agent is currently controlled.

Mode Description
Idle (default) Currently the agent is not under any particular control.
Waypoint The agent is currently following a waypoint path on the map.
Plan The agent is currently following instructions from a plan.
Manual The agent is currently following manual instructions from a remote.

Security model

The security model of OctoMY has some intrinsic complexities worth documenting.

For one, trusting a random node is difficult. How can you be sure they are who they claim?

Secondly, with the advanced communication patterns that OctoMY invites, there are many cases and edge cases that need to be addressed.

For example, any node should be able to communicate with any node with some level of granular permissions. Some nodes should have authority over others, including control over whom they can interact with.

Thirdly, the system is distributed with no guarantees of consisten commnucation between nodes. With a break between groups of nodes, we need to somehow gracefully adapt once communications are re-established.

Let's start by establishing some ground rules.

  1. Local authority a. Each node has full authority over itself. If you can access the physical ui of a node, you should be able to take full control over it and shut out any other node from ownership. b. Each node has a "local only" mode that shuts down all communication and execution of plans from external sources, allowing you to make changes to config in the case of security escalations.

  2. There exists 3 levels of trust: a. No trust. This is the default, there is no access. b. General trust. The nodes can collaborate with other nodes and control each other to a certain extent. Nodes have no access to security settings such as which other nodes we should trust. c. Skeptron. The node marked as skeptron becomes the full master of our node and is allowed to make any change available, including chnaging security settings.

  3. Granular authorization

  4. In general trust, it is possible to specify more granularity of trust. Each node set the rules for what other nodes can do. Examples would be "can move" or "can use camera".

  5. In skeptron mode all granular rules are ignored.

  6. A node can accept membership into one or more groups. The membership in the group has two attributes; a. The control we have over the group b. The control the group have over us

A typical setup is for one node to have skeptron over a group and then there are zero or more nodes in the group that have skeptron or general trust to the group, allowing the owner to control them. This makes it easy to manage relations. To gain control over a new node simply add it to the group.

  1. Plans a. A plan can dictate configuration changes, including permission changes. b. A plan can be executed on a node from another. It will perform all the steps that are permissable. If that node has skeptron authority, the plan will execute completely. c. The ui should warn if there are missing permissions before execution d. If permissions are changed during execution, the plan should have self-correcting provisions made to handle this. e. If node A has skeptron authority over node B and start executing a plan that requires skeptron permissions on B, the execution will continue with those permissions even when A and B are no longer in comms.

  2. Permission delegation a. A node with skeptron over two nodes A and B can delegate permissions it has over one to the other. For example it can give A skeptron access to B. b. A node can give up it's permission (but not regain them alone) c. A node can give up trust as part of a plan's execution. For example if node A has skeptron authority over node B, then a plan on node B can remove this skeptron (given the permission of the plan executor has access to do this).

Glossary

Term description
### Node An intependent program with an identity in the OctoMY distributed system. Example node types are Agents (robots), Remotes (handheld remote controls) and Hubs (stationary remote controls with access to online resources).
### Agent A node that runs on board a robot.
### Remote A node that runs on a handheld device such as a smartphone enabling the ueser to remote control one or more agents.
### Hub A node that runs on a computer such as a cloud server or laptop enabling the ueser to remote control one or more agents.
### Zoo This is a social media platform for OctoMY agents to get to know each other, communicate and collaborate.
### Delivery The creation of a new node, such as an Agent or Remote. When the4 node is an Agent it is often referred to as the "birth" of the node.
### Configuration The process of setting up the hardware on which a node runs. This is most important for Agetns because they will interface with controller circuits that run a robot.
### Discovery The process of finding other nodes that are candidates for pairing. It works by the nodes broadcasting their status as "discoverable" on local network and via zoo discovery service. When two nodes see eachother, they become available for pairing.
### Pairing The process of assigning trust to nodes that were previously found in the discovery process. OctoMY provides several ways to enable the verification of the identity of nodes.
### Unboxing The process of integrating a new node into OctoMY. After installation of the node software (Agent, Remote or Hub), it has the following steps: delivery, configuration, discovery and pairing.
### Birth See delivery
### Trust In the pairing process, the user will assign trust to a discovered node. This will mark the node as either "trusted" or "untrusted". Untrusted nodes will be hidden while trusted nodes are made available for communications (see comms ). If trust cannot yet be determined, the decision can be deferredby the user selecting "ignore", which simply avoids assigning any trust but does not hide the node in question.

Lobe concept

A lobe in the context of OctoMY is a real-time software function running on a controller that is responsible for controlling one or more actuators, possibly in feedback loops with sensors.

Why is this important?

To achieve lowest possible latency and to ensure real-time characteristics, it is not desirable to stream control signals out of the controller to make decision about actuator movements. It is better to stream higher level asynchronous control signals to the controller and let the lobe in the controller handle the actual real-time update.

Controller types implement a standardized interface Controllers can have 0 or more actuators Controllers can have 0 or more sensors Controllers are configured in two ways; controller native config, controller generic config The controller type spesific settings are available in the controller native config. The settings that are common for all controller typesare available in the generic controller config. The number of actuators & sensors a controller exposes in the generic config is determined in the controller native config. The controller native config is optional for simple controller types.

Example native controller settings are: Connection parameters for serial, micro controller pin mapping and power settings. Example generic controller settings are: Actuator enabled status, actuator limp status, sensor enable status, sensor name and sensor filtering.

Decoupling of sensors and actuators is done via name mappings. Each actuator and sensor is given a name string. In the mapping the actuator or sensor name is associated with corresponding items in the Stanza.

The mapping editor has a "automap" button that maps all items with the same name. For example if an actuator is called "throttle" and there is an item in the stanza called "throttle" those will be connected.

Stanza

Stanzas are a logical constellation of lobes, actuators and sensors that makes an agent act in a certain way. As an example you may have a legged robot with two stanzas, one "walking" stanza and one "interaction" stanza. The walking stanza will link all the servo actuators to the walking lobe, while the interaction stanza will connect the two front most legs to a "fine control" lobe. The waliking lobe will give the user an interface to steer the robot while a stable gait is generated in real time. The fine control lobe will allowe the user to carefully point the limbs in real time to poke and grab in the environment.

The actuators can only be under the control of one lobe at the time. Switching between stanzas allows the user to quickly chose between "modes".

Lobe types

Each lobe has a type which comes with an interface. For example the "locomotion" lobe type allows the path-finding subsystem to direct the agent towards the desired target location. The manipulator lobe type gives an interface for interactively grabbing and moving objects.

Hardware

Actuators

Sensors

Control

Controller interface

Servotor32

ArduMY

Gait planning

User interface

Actuator control

Pose control

Path planning

Intercom

Face

Connection

Activity

Intent

Stack

Wizard

Communications

Pairing

Discov ery

Identity

Delivery

Facial expression

Voice

How to handle variability of controller.

Project priority and milestones

Project parts

Part Description
Build system How the project is built from source into artefacts
Complete UX Documentation for the user experience
Wiki Community maintained documentation
Blog A stream of news about the projects intermixed with time relevant tidbits and musings
Documentation The official reference works for how to operate and partake in development of the project
Qt static build System to build Qt reliably
MVP Hub The first published version of Hub
MVP Remote/Agent The first published version of Remote and Agent
MVP Zoo The first published version of zoo
Google Play deployment Deployment of apps to Google Play
Youtube channel Market the project on YouTube
Reddit channel Market the project on Reddit
ArduMY Custom micro controller runtime for running robots
External controller support Support for 3rd party controllers
External platform support Support for 3rd party platforms like ESP32, tinsy, jetson, rpi etc.
Organization formation Start OctoMY foundation
OctoMY seal Sell OctoMY partnership to Hasboro

Project organizational structure

Our organizational structure is losely based on the structure of Linux kernel team.

Since we are much smaller, we follow an organic growth path which divides the responsibilities into tiers as the workload grows out of the capacity of the original role. For example, Leo might give an additional team member "Alice" maintainer status over a certain part of the project. This part grows in complexity until Alice can no longer cope alone. She will then recruit "Bob" to serve under her to take over part of her task.

Each member is responsible for the members they directly recruit. Each member recruited will fall into the tier structure and receive a title as prescribed.

When a higher level member steps down, the responsibility falls to her supervisor until a replacement can be found. It is common that one of her subordinates step up in a promotion, or that we lean on internal mobility in some other way.

1. Leo (Benevolent Dictator 'BD')

2. First-Level subsystem responsible (Captain)

3. Second-level subsystem responsible (Lieutenant)

4. Patch Reviewers (Enlists)

5. Project Developers / Contributors (Troopers)

6. Stability team (Marine)

7. Security Team (Marine)

8. Corporate Contributors

Development Workflow

  1. Developers submit patches to the relevant subsystem maintainer via LKML.
  2. Patch reviewers provide feedback and request improvements.
  3. Second-level maintainers merge accepted PRs into their branches.
  4. First-level maintainers merge accepted PRs into their branches.
  5. BD merges everything into the mainline kernel during the merge window.
  6. Stable maintainers

Key Characteristics of the OctoMY™ project Team

Meritocracy – Influence is earned through contributions. Decentralized – No single company owns OctoMY. Open – Everything happens in an open for all to see platform (GitLab). Pull Request base development – Every piece of code is scrutinized by a veritable barrage of automated test suites, talented developers and aspiring maintainers before being accepted. No line of code will be accepted unless it is flawless.

OctoMY™ GitLab (OGL)

Project organizational structure

A. Core Framework & API

B. Networking & Communication

C. Robotics & Hardware Integration

D. User Interface & UX

E. Build System & CI/CD

F. Documentation & Developer Relations


Debug enabled