Distributed systems with

Delivered at Scuola Gorini 2026

Paolo Bosetti

University of Trento

2026-Sep-03

Contents

  • Requirements
  • What is
  • Concepts
    • Broker-based networking
    • MADS Agents
      • Types of agents: source, filter, sink
      • Many ways to implement an agent
      • Data sources in Arduino
  • Designing a network
  • Deployment
  • Advanced features

Requirements

is a polyglot environment: you might use C, C++, Rust, Python, R, Lua.

That said, C++ is its core language, and for using it you need a C++ environment

CMake version

More recent versions of CMake may not work with some of the MADS dependencies. Please stay on the tested 4.2.1 version

Developing on Linux

Core development is made in CMake 4.x and Clang, tested on Ubuntu 22.04 and 24.04

  • IDE of choice is Visual Studio Code, with the MADSCode extension
  • Be sure to have the proper packags installed and clang selected as compiler:
sudo apt update
sudo apt install clang cmake-curses-gui git libssl-dev
sudo update-alternatives --install /usr/bin/cc cc /usr/bin/clang 100
sudo update-alternatives --install /usr/bin/c++ c++ /usr/bin/clang++ 100

Then go to https://git.new/mads, download the latest .deb package and install with:

sudo dpkg -i Mads-v2.x.x-Linux-<platform>.deb

Warning

Pick the proper <platform>: x86_64 for Intel, aarch64 for ARM machines

Developing on Windows

Core development is made in CMake 4.x and Visual Studio 2022, tested on Windows 11

  • IDE of choice is Visual Studio Code, with the MADSCode extension
  • Visual Studio (Community Edition is fine) is only used as compiler, not as IDE
  • When installing VS be sure to add C++ tools and CLI libraries
  • Also install CMake 4.2.1 from GitHub

Then go to https://git.new/mads, download the latest .exe installer and follow the graphical install

Developing on macOS

Core development is made in CMake 4.x and Clang, tested on macOS 26 (Tahoe)

  • IDE of choice is Visual Studio Code, with the MADSCode extension
  • Apple Xcode tools must be installed (to have Clang working)
  • Also install CMake 4.2.1 from GitHub

Then go to https://git.new/mads, download the latest .dmg installer and open it it. Then drag the usr folder into your home directory, and add the path ~/usr/local/bin to your PATH environment variable and remove the unsafe attribute:

xattr -dr com.apple.quarantine ~/usr/local

How to change your PATH

  • If your shell is zsh, then look here
  • If your shell is bash, then look here

Test that it works

Open a terminal (Developer PowerShell on Windows) and type:

mads -h
Mads command line interface version v2.4.3
Usage:
  mads [OPTION...]

  -i, --info                   Print information on MADS installation
  -p, --prefix                 Print MADS linstall prefix
      --plugins                List plugins in default plugins directory
      --keypair [=arg(=mads)]  Generate ZMQ CURVE keypair
  -f, --force                  Force operation (if applicable)
      --rooms [=arg(=5000)]    List rooms advertised on the network
  -j, --json                   Output in JSON format (where applicable)
  -v, --version                Print version
  -h, --help                   Print help

If you get an error:

  • be sure that your PATH variable contains the folder where the mads command has been installed
  • be sure that your OS matches one of the versions above listed
  • report back to https://github.com/pbosetti/MADS/issues, carefully describing your issue and configuration

What is ?

Brief description

MADS is a framework (i.e. a set of tools and libraries) to implement a collection of possibly distributed processes that collect, manipulate, store and present information

  • based on IP connectivity (UDP and TCP)
  • runs on Linux, macOS and Windows, on Intel and ARM architectures
  • it is easily extensible with customized processes
  • it is centralized and broker-based
  • it is safe and industry-ready (encrypted)
  • it is lightweight and easy to learn
  • it is akin to ROS2, Apache Spark, Zenoh

Common tasks: acquisition

You want to acquire data/signals:

  • from microcontrollers via serial connection (e.g. Arduino)
  • on microcontrollers with an ARM Linux OS (e.g. Arduino Uno Q, Raspberry Pi, Beaglebone)
  • on microcontrollers with WiFi (Arduino Uno R4 WiFi only)
  • from custom/vendor API in C/C++, Python or Rust

Definition

MADS Processes that acquire and produce a data flow are called source agents

Common tasks: manipulation

You want to manipulate data/signals:

  • with custom algorithms implemented in C, C++, Python, Rust, R
  • ML inference by models in ONNX format (onnx.ai)
  • simulation models in Functional Mock-Up Unit (FMU) format (exported from Simulink)

Definition

MADS Processes that manipulate a data flow are called filter agents

Common tasks: logging/presenting

You want to consume or present data/signals:

  • storage/logging straight to MongoDB databases
  • logging to HDF5 format (for training ML models)
  • realtime presentation via Rerun.io
  • custom data consumers in C++, Rust, Python, R

Definition

MADS Processes that consume a data flow (for logging or presenting, or acting on the field) are called sink agents

This is just a preview

The rest of this presentation will be available on Sep. 2026

Concepts

Infrastructures for distributed systems

Context

Distributed systems need distributed information and computation

Challenges

  • Reachability
  • Topology
  • Throughput
  • Latency
  • Scalability
  • Security

Solutions

  • REST/API services: HTTP/HTTPS based, simple and proven, but N-to-1 only, large overhead
  • Message-Queuing protocols: flexible topology, tiny overhead, often very low-level solutions
  • Mixed/custom solutions: fragile and difficult to scale/integrate

Context: REST/REST-like solutions

Characteristics:

  • Only the server’s URL/IP must be known
  • Each edge is a REQ/REP initiated by the client
  • Node-to-node direct communication impossible, unless all URLs/IPs are known
  • Difficult to scale:
    • server resources
    • network topology

Note

It is information-consumption oriented.

REST S Server n5 n5 S->n5 🔴 n1 n1 n1->S n2 n2 n1->n2 🔴 n2->S n3 n3 n3->S n4 n4 n4->S n5->S

Context: Message-Queuing protocols

Advantages over REST:

  • Broker-based networking
  • wire protocol is lightweight (minimum overhead)
  • only broker URL is needed
  • message t1 can flow from n1 to n6
  • flexible topology
  • highly scalable

Note

It is information-distribution oriented.

mq B Broker n3 n3 B->n3 t1 n4 n4 B->n4 t2 n5 n5 B->n5 t3,t4 n6 n6 B->n6 t1 n1 n1 n1->B t1 n2 n2 n2->B t2 n3->B t3 n4->B t4

Context: federation

mq B1 Broker 1 n3 n3 B1->n3 t1 n4 n4 B1->n4 t1,t2,t3 n5 n5 B1->n5 t2,t3 n6 n6 B1->n6 t1,t14 n1 n1 n1->B1 t1 n2 n2 n2->B1 t2 n3->B1 t3 n4->B1 t14 B2 Broker 2 n4->B2 t1,t2,t3 B2->n4 t14 n11 n11 B2->n11 t1,t14 n12 n12 B2->n12 t3 n13 n13 B2->n13 t2,t14 n14 n14 n14->B2 t14 n11->B2 t11 n12->B2 t15

Definitions

Typically, nodes may act as sources (produce information), filters (elaborate), or sinks (consume information). The node n4 acts as a brigde that federates two sub-networks

Context: alternatives

Pros Cons Proto. Prod. Learning
MQTT lightweight, proven low-level, no fed’n 🟠 🟢

ZeroMQ lightweight, very flexible, proven low-level, fed’n is complex 🟠 🟢

OPC-UA powerful, industry-based, fed’n heavy, complex, vendor-dependent, limited portability/integrability 🔴 🟠🟢

Zenoh flexible and powerful, fed’n high abstraction, low-level 🟢 🟠

Apache Spark designed for high-loads & datacenters, fed’n Java-based, limited integrability, unsuited to µC 🔴 🟢

ROS2 flexible, high level, feature rich long learning curve, robotics oriented, no fed’n 🟢 🟢

easy, ZeroMQ-based, portable, flexible, polyglot, fed’n young (3 years) 🟢🟢 🟠🟢

Note

Low-level: framework only/mostly taking care of data communication/distribution, where business logic must be implemented every time; portability: different platforms/architectures; integrability: against existing solutions; fed’n means federation; learning curves are subjective and qualitative.

Agents

Just a process in a computer
  • A network is made by one broker and many agents
  • Agents are processes: whether they run on a single computer or on a multitude of networked computers is irrelevant (except for throughput and latency)
  • Agents communicate each other via a TCP/IP network and only through the broker
  • The broker is completely transparent and data-agnostic
  • The process running the broker also distributes agents settings in REQ/REP fashion
  • Information is channeled/routed/organized via topics, e.g. measurements/force/X
  • An agent can publish on a topic and can subscribe to anther (to receive asynchronous updates)

Agents: types

Source agents

  • Acquire information from the field:
    • sensors
    • peripherals (TTY, GUI)
    • other protocols
  • Publish information on the MADS network under one or more topics
  • Publishing may be timed or event-based

source sensor sensor agent agent sensor->agent peripheral peripheral peripheral->agent broker broker agent->broker t1

Agents: types

Filter agents

  • Manipulate information:
    • filters
    • controllers
    • gateways
  • They subscribe to a topic, elabrate the received data, and publish back new data on a different topic
  • Publishing is mostly event-based

source broker broker agent agent broker->agent t1 agent->broker t2

Agents: types

Sink agents

  • Dispose of information received by other agents via broker:
    • to GUI (plots, charts, dashboards)
    • to disk (JSON files, HDF5)
    • to database (MongoDB)
    • to other protocols
  • Only deal with data coming from topics they are subscribed to
  • Typically event-based

source broker broker agent agent broker->agent t3

Data format: JSON

  • MADS agents exchange data as JSON objects, because of its flexibility
  • Underlying C++ library is nlohmann::json
  • Actual wire-format can be JSON (ASCII) or MsgPack (binary), per-agent negotiable
  • Directly maps to what you log in MongoDB
  • Directly maps to Python dictionaries

Incidentally: why MongoDB?

MongoDB is a schemaless, NoSQL database server: it organizes data in collections of JSON documents

Advantages

  • Data collection architectures may change (new agents, different data set-up)
  • A schemaless database allows to carry on data collection even when its structure changes
  • Still reasonably fast (20–250 kwrites/s)
  • Maps nicely to JSON objects

Limitations

  • Dealing with non-consistent schema is demanded to downstream consumption (but doable!)
  • SQL queries are easier than MongoDB queries (but AI helps here!)
  • SQL servers can bear higher workloads (1.2x–1.5x)

Agents: implementation

Requirements

MADS has beed designed with requirements of flexibility and easy extensibility

An agent can be implemented in a number of alternative ways:

  • C++ process, linked to the MadsCore shared library (#include <mads.hpp>)
  • C process, linked to the MadsCore shared library (#include <mads_c.h>)
  • Python script FFI-linked to the MadsCore library (from mads_agent import Agent)
  • C++ plugin, with minimal API surface (3 methods)
  • Rust plugin, with minimal API surface (3 methods)
  • Python plugin (a binary that loads a Python module at runtime)
  • R plugin (a binary that loads a R script at runtime)
  • Lua plugin (a binary that loads a Lua script at runtime)

Agents: implementation

The choice depends on personal knowledge/skill and task requirements:

Method Performance Flexibility Production-ready Base install
C++ process ⭐️⭐️⭐️⭐️⭐️ ⭐️⭐️⭐️⭐️ ⭐️⭐️⭐️⭐️⭐️
C process ⭐️⭐️⭐️⭐️⭐️ ⭐️⭐️⭐️⭐️ ⭐️⭐️⭐️⭐️
Python script ⭐️ ⭐️⭐️⭐️⭐️⭐️ ⭐️⭐️
C++ plugin ⭐️⭐️⭐️⭐️⭐️ ⭐️⭐️⭐️ ⭐️⭐️⭐️⭐️⭐️
Rust plugin ⭐️⭐️⭐️⭐️⭐️ ⭐️⭐️⭐️ ⭐️⭐️⭐️⭐️⭐️
Python plugin ⭐️⭐️ ⭐️⭐️⭐️⭐️ ⭐️⭐️ ⛔️
R plugin ⭐️⭐️ ⭐️⭐️⭐️⭐️ ⭐️⭐️ ⛔️
Lua plugin ⭐️⭐️⭐️ ⭐️⭐️⭐️ ⭐️⭐️ ⛔️

MADS-NET: a repository of pre-made agents

The github.com/MADS-NET page provides a list of open source, ready available plugin and custom agents repositories for solving common tasks, which may be immediately useful, or provide a template on which to build upon:

  • Python/R/lua plugins
  • HDF5 logging
  • ML inference of ONNX models
  • FMU plugins
  • User interfaces
  • JSON schema validation
  • Arduino I/O
  • and more

MADS-NET repository MADS-NET repository MADS-NET repository MADS-NET repository

MADS-NET: a repository of pre-made agents

To install a custom agent from MADS-NET:

From source

  • Clone the repo
  • Configure and compile:
    cmake -Bbuild -GNinja
    cmake --build build
  • Test from build/toolname
  • Install (with sudo if needed):
    cmake --install build

Pre-compiled (subsection)

  • List available:
    mads package --list
  • Info on the one you want:
    mads package --info <package>
  • Install (with sudo if needed):
    mads package --install <package>

Warning

mads package is not a full-fledged package manager: it only supports the latest MADS version. Build from source if you stuble into problems

Agents: Arduino-based

  • Cheapest and fastest way to ingest field data into a MADS network
  • Three possible, complementary solutions:
    • arduino.plugin and a custom .ino sketch that prints a JSON string over serial — any Arduino, but must be serial-port connected to an agent running on separate device
    • arduinoQ.plugin, only works on an Arduino Uno Q: the agent runs on the CPU, a custom .ino on the MCU, they communicate via RPC — Uno Q only, standalone
    • arduino_mads: an Arduino-native library that provides low-level message passing to a MADS-network — requires Ethernet- or WiFi-equipped Arduino, standalone, feature-limited

Tip

The arduino.plugin, despite its name, works with any micro that can print on a serial port a JSON string

Agents: Arduino-based

  • A new, powerful Arduino plugin is in preparation, with direct selection of I/O pins from mads.ini, with no programming required on the Arduino side
  • It exploits the https://github.com/pbosetti/ArduinoDriver library and firmware, which provides a generic, low-level USB interface to Arduino I/O pins, and is compatible with most Arduino boards
  • Supports read, write, stream, and interrupts
  • Expected release: Fall 2026 released
  • Plugin name: ArduinoIO.plugin

ArduinoDriver

ArduinoDriver

Commands and tools

provides a number of command line tools to manage and monitor a network

Common commands

  • mads broker to start a broker
  • mads [source|filter|sink] to load a C++ plugin
  • mads [rsource|rfilter|rsink] to load a Rust plugin
  • mads plugin to create a plugin template
  • mads logger to log network traffic to MongoDB
  • mads echo to watch network traffic
  • mads top to monitor agents
  • mads package to install a pre-made plugin from MADS-NET

mads broker: centralized management tool

The broker does much more than just routing messages: it also provides a centralized management of the network

  • ensures that all agents run on compatible versions of the MADS framework
  • distributes to each agent (when it starts) its configuration from a local mads.ini file
  • provides Over the Air (OTA) distribution of plugins binaries to remote agents
[agents] # common to all agents
frontend_address = "tcp://localhost:9090"
backend_address = "tcp://localhost:9091"
settings_address = "tcp://localhost:9092"
timecode_fps = 25
wire_format = "json"
compression = "auto"

[source]
pub_topic = "measurements/force/X"
attachment = "force_sensor.plugin" # OTA

[filter]
sub_topic = ["measurements"]
pub_topic = "filtered/force/X"

[sink]
sub_topic = "filtered"

Agents and the mads.ini file

  • A broker advertises its presence on the network, each broker in a virtual room with possibly different name (mads by default)
  • Each agent needs the mads.ini file to start
  • The agent searches for it in this order:
    1. a broker URI or a file path passed by the --settings command line option
    2. a room name if the --room command line option is used
    3. a broker running on tcp://localhost:9092 (default)

Note

Start order of broker and agents is irrelevant, as well it is restarting the broker while agents are running: they will automatically reconnect to the broker when it becomes available again

The only way to reload the mads.ini file is to restart the agent

GUI commands

Two commands provide GUIs to monitor and control a MADS network:

  • mads director: coordinates the execution of multiple MADS tools on the same machine
  • mads chat: reads and writes messages to the MADS network
    (installed with mads package --install mads-chat)

mads director

mads chat

Utility commands

  • mads doctor: help fixing MADS configuration issues
  • mads ini: create a template mads.ini file
  • mads [record|play|bag]: record and replay network traffic to a bag file (and inspects it)
  • mads up: headless version of mads director (for remote control)
  • mads service: install a MADS tool as a system service (Linux only)
  • mads update: check for updates and provide packages URLs
  • mads fsm: creates a finite state machine agent template from a Graphviz scheme
  • mads federate: launch a federation agent for connecting two MADS networks

Common, general purpose plugins

  • mads sink rerunner.plugin: a sink agent that sends data to Rerun.io for realtime visualization
  • mads sink validator.plugin: a sink agent that validates JSON data against a schema
  • mads sink hdf5.plugin: a sink agent that logs data to HDF5 files
  • mads [source|filter|sink] arduino.plugin: a source/filter/sink agent that communicates with a microcontroller via serial port

Python plugins

Python plugins are loaded by a dedicated mads python agent, which is installed with mads package --install mads-python. It is a Python interpreter that loads a Python module at runtime

To allow users to use their own Python version, the mads python agent is not part of the base MADS installation, but is available as a separate package from MADS-NET/python_agent to be compiled against your Python of choice

Rerun interface

Rerun window (see https://rerun.io)

Anatomy of a plugin: C++

class MySource : public Source<json> {
public:
  using Source::Source; // inherit constructors

  string kind() override { return PLUGIN_NAME; }

  return_type get_output(json &out, 
    vector<unsigned char> *blob = nullptr) override {
    out.clear();
    if (!_agent_id.empty()) out["agent_id"] = _agent_id;
    // FILL out with contents
    return return_type::success;
  }

  void set_params(const json &params) override {
    Source::set_params(params);
    _params["some_field"] = "default_value";
    _params.merge_patch(params); // merge with INI parameters
  }

  map<string, string> info() override { 
    return {{some_filed, _params["some_field"].get<string>()}};
  };

private:
  // some private fields
};
  • Inherit a base class (Source, Filter, Sink)
  • Implement a few (3–4) methods:
    • kind(): returns the plugin name
    • get_output(): fills the output JSON object with data to be published
    • set_params(): sets parameters from the INI file
    • info(): returns a map of information about the plugin

Anatomy of a plugin: Python module

import json

# Specify that this is a source agent
mads.agent_type = "source"

# Executed once at startup
def setup():
  print("[Python] Setting up source...")
  print("[Python] Parameters: " + json.dumps(mads.params))
  mads.state["n"] = 0

# executed in a loop, to produce data to be published
def get_output():
  mads.data = {"list": [1, 2, 3, 4], "n": mads.state["n"]}
  mads.state["n"] = mads.state["n"] + 1
  mads.data["processed"] = False
  return json.dumps(mads.data)

Warning

"source” is the default agent type. If mandatory functions are not implemented, the agent fails to start

  • It’s a module, not a script
  • Filters have process(), sinks have deal_with_data()
  • Gets implicit access to the mads object:
    • mads.params: parameters from INI
    • mads.state: a dictionary to store persistent state between calls
    • mads.data: the data to be published (as JSON string)
    • mads.topic: the topic of the last received message

MADS message example

Publihed data is decorated by common fields (lines 8–14):

  • agent_id: to distinguish different instances of the same agent
  • period: the nominal time between two consecutive publications (in ms)
  • timestamp: ISO 8601 timestamp of the publication
  • timecode: seconds since the last midnight, rounded to the last timecode_fps frame rate (for binning!)
{
  "my_data": {
    "id": 131,
    "payload": "rHIR]aDLI",
    "payload_length": 10,
    "values": [1, 2, 3, 4]
  },
  "agent_id": "",
  "hostname": "Fram-IV",
  "period": 100,
  "timecode": 49683.52,
  "timestamp": {
    "$date": "2026-08-06T13:48:03.540+0200"
  }
}

Important

See the guide for timing and synchronization considerations

Design a network

flowchart LR
    n1["`mads.ini file`"] --> n2["make graph"]
    n2 --> n3["complex?"]
    n2 --> n1
    n3 -- no --> n4["`prototype 
    plugin`"] 
    n3 -- yes -->n5["`make fsm 
    or API agent`"]
    n4 --> n6["fast?"]
    n6 -- yes --> n7["create service"]
    n6 -- no --> n8["template agent"]
    n8 --> n7
    n5 --> n7

    n1@{ shape: rect}
    n2@{ shape: proc}
    n3@{ shape: decision}
    n4@{ shape: proc}
    n5@{ shape: proc}
    n6@{ shape: decision}
    n7@{ shape: proc}
    n8@{ shape: proc}

Design the network graph via mads.ini

[broker]

[forces]
pub_topic = "imu/forces"

[accelerations]
pub_topic = "imu/accelerations"

[gyro]
pub_topic = "gyro"

[ego]
sub_topic = ["imu", "gyro"]
pub_topic = "ego"

[rerun]
sub_topic = ["imu", "ego", "gyro"]

[dangling]
sub_topic = ["test"]

mads accelerations accelerations ego ego imu gyro accelerations->ego imu/accelerations via imu rerun rerun imu ego gyro accelerations->rerun imu/accelerations via imu dangling dangling test [!] ego->rerun ego forces forces forces->ego imu/forces via imu forces->rerun imu/forces via imu gyro gyro gyro->ego gyro gyro->rerun gyro

Note

Agents with dangling topics have dashed borders. Solid edges are explicit topics, dashed are wildcard topics, dotted are implicit topics (same as agent’s name)

Implement the agents

  • If possible, reuse existing agents/plugins from base install or MADS-NET
  • If not, implement a new agent:
    • if its logics fit the simple source/filter/sink model, create a plugin
    • if its logics are more complex, create a finite state machine agent or a custom agent based on the MADS API
  • Python plugins: start with examples in https://github.com/MADS-NET/python_agent
  • C++ plugins: create a template with mads plugin -t <source|filter|sink>
    and fill in the methods

Commands help:

Always use mads <command> --help to get a list of options and usage examples

If you are on macOS or Linux, you can also use man mads-<command> to get a more detailed description of the command and its options

Deployment

At the moment, only the Linux platform is expected to be used for headless devices (e.g. Raspberry Pi, Beaglebone, etc.) and for production deployments

On Linux, the mads service command allows to install a MADS agent as a system service (daemon), so that it starts automatically at boot time and can be managed with standard system commands. So, if your agent is launched as mads source imu.plugin, you can install it as a service with:

mads service mads_imu source imu.plugin 

This only previews the service file. Check if its OK, then install with:

sudo mads service mads_imu source imu.plugin 
sudo systemctl enable mads_imu.service

Then that agent will start automatically at boot time

Performance considerations

  • Broker can sustain up to 3M msg/s with 1kB payload, up to 30M msg/s when multithreaded (a mads.ini setting)
  • As of version 2.4.3, MADS broker sustains a configurable maximum number of clients (memory limited)
  • A single agent can sustain up to typ. 40k msg/s (with 1kB payload), depending on the processing load and the CPU speed
  • Higher payload may result in dropped messages (eg. ~0.05% at 50k msg/s), but the connection is robust
  • Increasing message queue (a mads.ini setting) may cope with higher but irregular loads (ie. bursts exceeding the processing capacity of the agent)

Warning

Up to v2.4.3, timings relies on individual device clocks, which have to be synchronized (eg. via NTP) to avoid time drifts. In a coming version (currently in development), a clock synchronization mechanism will be implemented even on devices with no RTC and no NTP access

Advanced features

FMI Interface

POV: you have a Simulink model that you want to integrate into a MADS network, e.g. to simulate a physical system or a control algorithm (Digital Twin)

  • Be sure that your Simulink model has Input and Output ports
  • Make it parametric as much as possible
  • Save it as model exchange FMU v3.0
  • The generated FMU can be loaded as a filter agent by the mads fmu agent
  • The simulation time (TET) must be smaller than the timestep

A Simulink model with Input and Output ports

Tip

The list of simulation software that can export FMU v3.0 is available at https://fmi-standard.org/tools/

ONNX models

POV: you have a trained ML model and you want to integrate it into a MADS network, e.g. to perform inference on data collected from the field

  • Quite similarly to the FMU case, there is the mads onnx agent that loads an ONNX model and runs inference on data received from the network
  • it can be used both for as a filter and as a source agent:
    • an ONNX filter agent performs inference on data received from the network and publishes the results back to the network
    • an ONNX source agent performs inference on data received from a peripheral (e.g. a camera) and publishes the results back to the network
  • The ONNX model must be exported from the training framework (PyTorch, TensorFlow, etc.) in ONNX format and must be compatible with the ONNX Runtime version used by the mads onnx agent (currently v1.26.0)

Use cases

Who’s using MADS?

NovaWalk

  • NovaWalk is a robotic walker for rehabilitation of patients with neurological disorders
    • Uses an impedance control strategy to drive the motor wheels according to the patient’s gait (load cells, IMU, encoders, cameras)
  • A Raspberry Pi 5 running MADS is the central controller of the system, which collects data from sensors and peripherals, runs the control algorithm, and sends commands to the motors
  • Certified for medical use, CE marked

NovaWalk robotic walker

INSA MFJA

  • MFJA is a hybrid research-training shopfloor for Industry 4.0, part of INSA Toulouse, France
  • MADS is used for collecting machining data from up to 20 machining centers, providing real-time shopfloor monitoring and data logging for optimizing energy consumption

INSA MFJA

MirrorWorld PRIN 2022

  • Project task: to create a digital twin of an industrial setting to mirror operators behavior to check for personal safety
  • Fuses data coming from wearable devices, 2-D and 3-D cameras, AI image processing to provide a real-time digital twin of the factory floor

MirrorWorld PRIN 2022

…and remember