How To Use ARC With Microcontrollers

Introduction

This guide explains how to use microcontrollers to implement tight closed‑loop control while working with the ARC Robot Software (Synthiam). ARC runs on a PC and is excellent for high‑level behavior, UI, and visualization, but general‑purpose operating systems cannot guarantee the low latency and deterministic timing required for some closed‑loop tasks. Offloading those real‑time control functions to microcontrollers improves responsiveness, accuracy, and system modularity. This document highlights the benefits, common use cases, hardware and software considerations, and how to integrate microcontrollers with ARC.

Limitations of ARC on a PC for Closed‑Loop Functions

PCs and desktop operating systems are not real‑time environments: task scheduling, background processes, and OS jitter can introduce unpredictable delays. For closed‑loop control systems that require frequent sampling, precise timing, and low latency (for example fast PID loops or encoder counting for motion control), this unpredictability can degrade performance or cause instability.

Typical problems when running tight loops on a PC include:

• Variable loop timing (jitter) caused by OS scheduling.
• Latency introduced by USB, serial, or network communications.
• Limited access to hardware timers, interrupts, and high‑resolution peripherals.

Using microcontrollers for these tasks preserves ARC for higher‑level coordination while guaranteeing deterministic local control.

Utilizing Microcontrollers for Closed‑Loop Functions

Microcontrollers are purpose‑built for real‑time tasks. They provide low‑latency I/O, hardware timers, interrupt handling, ADCs, and peripherals such as quadrature encoder inputs. Distributing control across multiple microcontrollers can be both cost‑effective and scalable.

Key advantages

• Deterministic real‑time processing: hardware interrupts and timers allow reliable sampling and control intervals.
• Higher effective resolution and accuracy: dedicated controllers can poll sensors and run control loops at high rates.
• Cost efficiency and modularity: many inexpensive microcontrollers can be deployed to handle specific functions, reducing load on the PC.

A common pattern is to flash each microcontroller with a small custom firmware (often referred to as a custom EZB firmware) that performs the closed‑loop task and communicates only essential data to ARC. Where appropriate, the EZB communication protocol can be extended so firmware both sends telemetry to ARC and accepts high‑level commands. If desired, multiple functions can be consolidated into a single microcontroller, but often a one‑function‑per‑controller design simplifies development and debugging.

Examples of Closed‑Loop Functions

The following examples illustrate typical closed‑loop tasks that benefit from microcontroller‑based implementation.

Microcontroller Selection and Configuration

Choose a microcontroller that matches your functional needs and interface requirements. Common choices include Arduino (AVR, SAMD), ESP32, STM32, and specialized encoder/counting or motor‑control MCUs.

Selection considerations

• Processing power: required loop frequency and algorithm complexity (e.g., state‑space vs PID).
• Peripherals: ADC resolution, hardware timers, interrupt capability, quadrature encoder inputs, PWM channels.
• Communication: UART/Serial, I2C, SPI, CAN, or USB for integration with ARC.
• Memory and libraries: available flash and RAM for firmware and buffering.
• Power and form factor: voltage domains and board size constraints.

Configuration involves setting up the programming toolchain, pin mapping, peripherals (timers, ADCs), and robust communication parameters (baud rate, packet framing, retries). Where precise timing is required, make use of hardware timers and interrupts rather than polling loops.

Writing Code for Closed‑Loop Functions

Firmware for closed‑loop control typically includes sensor acquisition, filtering, the control algorithm, actuator output, and communication. Follow best practices to ensure reliable real‑time behavior.

Recommended practices

• Use interrupt handlers and hardware timers for deterministic sampling and encoder counting.
• Keep control loops lightweight and deterministic; use fixed‑point arithmetic if floating‑point is too slow.
• Apply appropriate filtering (low‑pass, complementary, or Kalman where needed) to sensor signals.
• Provide telemetry and diagnostic messages to ARC but avoid sending high‑frequency raw data unless necessary.
• Implement safety features: timeouts, watchdogs, overcurrent protection, and graceful failover.

Leverage existing libraries and examples for sensors, encoders, and motor drivers. Test control loops thoroughly with simulation or slow speeds before running at full performance.

Integrating Microcontrollers with ARC Robot Software

Integration typically means establishing a robust, low‑latency communication channel between ARC and the microcontroller and defining a compact protocol for commands and telemetry.

Common integration options

• Serial/UART: simple, reliable, and widely supported; use framing and checksums for robustness.
• I2C / SPI: for short, local buses between boards; often used for sensor networks.
• CAN: for multi‑node networks with robust bus arbitration in noisy environments.
• Wi‑Fi / Ethernet: for remote devices (e.g., ESP32); consider latency and packet loss.

Design your data exchange so ARC receives only the necessary state updates (e.g., position, error codes, or aggregate telemetry) while the microcontroller retains responsibility for high‑rate sampling and loop stability. Example: the Wheel Encoder Counter robot skill demonstrates a custom EZB firmware that extends the protocol so ARC can query encoder counts from the microcontroller: Wheel Encoder Robot Skill.

Video: Demonstration of the Wheel Encoder Counter skill and extended EZB firmware communicating encoder counts to ARC.

EZB Protocol

The EZB communication protocol defines commands and message structures for interfacing with peripherals (UARTs, I2C, digital I/O, PWM servos, etc.). The protocol documentation is available here: EZB communication protocol. The protocol can be extended to add custom commands and telemetry as demonstrated by the Wheel Encoder example.

When extending the protocol, keep message formats compact, versioned, and backwards compatible. Implement basic error detection (checksums) and sensible retry/backoff logic in both ARC and the firmware.

Conclusion

Offloading tight closed‑loop control to microcontrollers improves determinism, accuracy, and safety while letting ARC remain the high‑level orchestrator. This approach enables scalable, cost‑effective systems that combine the strengths of both PC software and embedded controllers. To start creating a robot skill that integrates with microcontroller firmware, see the Robot Skill Tutorial: Robot Skill Tutorial.