Home

DIY Mobile Robot Controller

A white paper for a Do-It-Yourself (DIY) Mobile Robot Controller (MRC), and a Community-developed and supported MRC Framework.

The "MRC" is a component of the “Robot Control System (RCS)” described in Section 1.1 on page 4 of FIRST’s Request for Proposal – 2027 and Beyond FIRST^® Robot Controller:

1.1 Complete Control System Capabilities
FIRST requires a Robot Control System (RCS) that consists of the following devices/capabilities:

• Mobile Robot Controller (MRC) – Main robot controller capable of controlling motor controllers and other actuators and receiving sensor data inputs (I2C, SPI, CAN, Serial, USB, and analog/digital inputs) …
• [...]

The "Community" is a vast worldwide network of highly capable mentors and students both inside and outside FIRST^®. Thousands of willing and capable mentors and students just within FIRST.

The Community is a free and virtually unlimited resource pool of prerequisite expertise in every aspect of MRC design and quality assurance.

Executive Summary

Over the past decade we've experienced the commoditization and wide scale adoption of inexpensive yet powerful general purpose MCUs, SoCs, Crossovers, SoMs, and SBCs (“Platforms”).

The capabilities and price points of these general purpose Platforms, together with the ever-expanding open source software offerings, have quickly obsoleted function specific device sectors. Commoditization and wide scale adoption of the Platforms means that designers and manufacturers will continue to improve their Platforms while maintaining compelling price points.

The availability of rich and mature cross-Platform RTOS ecosystems make it feasible for Teams to design and build custom MRCs for their robots (“DIY-MRC”).

Cost savings, customizability, scalability, agility, and future-proofing are just the surface benefits of the DIY-MRC. A Team designed and built MRC:

• broadens opportunities for Team and student engagement, creativity, and innovation,
• broadens the suite of essential skills that students can acquire through FIRST programs, and
• showcases the capabilities of the students of FIRST programs.

In short, the DIY-MRC brings substantial value to FIRST stakeholders. Not to mention that a DIY-MRC is fundamental to DIY-Robot programs such as FIRST^® Tech Challenge and FIRST^® Robotics Competition.

Platforms

A “Platform” is a Development Board (“DevBoard”), System on Module ("SoM"), or Single Board Computer (“SBC”);

• DevBoards and SoMs such as:
  • RP2040 “MCU” based DevBoards and SoMs,
  • ESP32 and STM32 “SoC” based DevBoards and SoMs,
  • NXP iMX RT “Crossover” based DevBoards and SoMs,
  • RPi CM4 SoM,
• and SBCs such as:
  • RPi Zero, xPi Zero SBCs,
  • Model B [Plus] SBCs,
  • 96Boards SBCs,
  • BeagleBoard.org SBCs.

A wide variety of COTS Platforms are available. For the purpose of the DIY-MRC, a Platform:

• has a 32-bit processor or greater; dual-core or greater,
• has one or more networking ports such as USB, RS485, I2C, SPI, CAN Bus,
• has zero or more I/O ports such as PWM, GPIO, UART, I2S, ADC, DAC, MIPI, and
• is supported by a RTOS.

Firmware Development

Over the past few decades, a wide variety of cross-Platform RTOS ecosystems have been developed. Among the popular ecosystems are:

• FreeRTOS from Amazon Web Services
• ThreadX from Eclipse Foundation
• Zephyr from Linux Foundation

The open source RTOS ecosystems are supported by cross-platform (Windows/Linux/Mac) development tools, debuggers, and IDEs such as VS Code, PlatformIO, and CLion, together with a growing number of open source libraries.

These ecosystems and development tools have brought firmware development to the mainstream.

Note

The referenced tools and open source works have permissive and/or complimentary licensing.

Framework

The MRC Framework/SDK ("Framework") is built on a cross-Platform RTOS.

Vertical scalability of the MRC is inherent to the cross-Platform Framework. In many cases, however, horizontal scaling of the MRC is the only feasible solution or otherwise the proper solution.

The Framework ensures that Team code, called "OpMode":

• can be coded to run distributively over a network of Platforms as simply and as seamlessly as running on a single Platform.
• can be coded in C/C++, plus any language runtime available on the RTOS:
  • available runtimes include Python, JavaScript, and Java ME.
  • likely any open source runtime can be ported to the RTOS.

The Community designs, develops, and maintains the open source Framework.

[Continued]

Motor Drivers

Any COTS Motor Driver or Motor Controller that has a PWM interface is supported by the Framework. Support for other interfaces are added as needed.

Teams purchase inexpensive 10A, 20A, …, 60A, brushed or brushless DC Motor Drivers as needed.

The high current switching circuitry of a Motor Driver or Motor Controller, and the high current pulses carried by DC Motor leads, are sources of electromagnetic noise. Thus Motor Drivers and Motor Controllers should be placed:

• as far as possible from the MRC components, and
• as close as possible to the motors they drive.

Environmental Protections

Analysis and mitigation of environmental threats (shock, electromagnetic noise, ESD, ...) presents yet another opportunity for students to acquire essential skills and to innovate.

The COTS Platforms can be plugged into a "I/O Board" (a "Carrier Board" or "Baseboard"). In the case of a SBC, the I/O Board is a "shield", "hat", "mezzanine", or "cape".

An I/O Board is a PCB. PCB design is now mainstream in virtue of the many online PCB design and production services.

Teams can design and produce custom I/O Boards and enclosures for their Platforms, or choose from a variety of boards, templates, and enclosures that are created by the Community.

A Team designed I/O Board can have environmental protections such as:

• A Custom mix of PWM, DIO, I2C, SPI, ADC, DAC, RS485, CAN Bus ports.
  • unneeded connectors are a vulnerability and can get in the way of the proper placement and orientation of necessary connection points.
• Shock proof connectors.
• Isolation transceivers, optocouplers, and/or opto-emulators.
• Voltage regulators and noise filters.
• Protective enclosures that provide:
  • electromagnetic shielding
  • waterproofing

Teams perform an analysis of the type and level of protections needed for their particular application. Teams also perform an analysis of the type of connectors, wiring, and shielding necessary, and in consideration of the level of serviceability needed.

Teams can scale environmental protections as needed. Typically,

• No protection is needed for development and bench testing,
• Medium level of protection may be needed for development bots and demo bots, and
• High level of protection is needed for competition bots.

Connectors and environmental protections need not be present where not needed. Thus the DIY-MRC is a greener solution.

[Continued]

Agility

FIRST competitions take place all around the world and in different climates and environments. Also:

• the MRC must function within all kinds of different mobile devices,
• the mobile devices change drastically from season to season, and
• the demands on the MRC change from season to season.

It is impossible for a commercially produced MRC to test for all climates, all environments, all devices, and all seasons. Invariably the commercially produced MRC will have significant flaws. It can take years for fixes or enhancements to be available.

The DIY-MRC has the advantage that fixes and enhancements can be available in a matter of days or weeks instead of years. Also, the I/O Board can be fixed or enhanced without having to change the Platform, and the Platform can be enhanced without having to change the I/O Board.

Moreover, if there is a disruption in supply of any given Platform, Teams can source other Platforms.

Quality and DEI

A commercially produced MRC is likely to cost around $500 plus shipping and duties. Not all Teams can afford a commercial MRC for the competition bot, plus additional commercial MRCs for each developer on the Team, and for each demo bot.

Moreover, a commercial producer does not have nearly as many resources, nor the global reach, nor the competition testing ability, nor the agility, that the Community has.

Competition Considerations

A competition has game constraints and wireless constraints. Therefore, communication with the Driver Station, the Field Management System, or any other competition system should be via closed-source library provided by FIRST, or via a device provided by FIRST (“Competition Controller”).

The Competition Controller (or library):

• provides wireless connections to the Driver Station and competition systems, and
• manages wireless activity in the competition venue.

Additionally, the Competition Controller might provide watchdog services, kill services, and/or automated inspection services to the DIY-MRC.

Turnkey MRC

The Community can develop several inexpensive turnkey MRC solutions for Teams that prefer turnkey solutions ("Community-MRC").

Also, the Control Hub, Expansion Hub, and roboRIO can continue to be options to cater to Teams that desire the features provided by those devices.

Teams have structural and coding options for their competition bots. Likewise, Teams have options for their competition MRC:

	Beginner	Intermediate	Advanced
Structure:	COTS Build System (REV, VEX, goBILDA, Studica, Robits, ...)	❮➖ Hybrid ➖❯	CAD/Print/CNC the bot
Coding:	Blocks	Java, Python, Lua	C/C++
MRC:	Turnkey (Community-MRC, NI roboRIO, REV Hubs)	DIY-MRC (Single-Platform)	DIY-MRC-Network (Multi-Platform)

TurboHUB

The "TurboHUB" is a Virtual Device that emulates the REV Expansion Hub. The TurboHUB provides:

• all of the functionality of the REV Expansion Hub,
• all of the features of the underlying Framework and Platform(s) that are not available on the REV Expansion Hub, such as SPI, CAN Bus, DAC, MIPI, ..., and
• the ability to distribute the processing of an OpMode across several Platforms.

With the TurboHUB, Teams can replace the REV Expansion Hub and/or the REV Control Hub with inexpensive COTS Platforms and devices. Teams can also use the TurboHUB to replace the roboRIO on their FRC demo bots.

The REV Expansion Hub protocol ("EH-Protocol") is found in the Extracted-RC repo. Where the Platform or Framework has features that are not supported by the EH-Protocol, the TurboHUB provides those features to the OpMode via virtual I2C devices.

Note

A virtual I2C device is not an actual I2C device. The virtual I2C device is a stub or proxy to a Framework Virtual Device. There is no communication on a I2C bus.

This technique allows the OpMode to have access to Platform and Framework features without requiring any changes to be made to the FTC control system software, namely the FTC SDK, the Robot Controller App, and the Driver Station App.

Some examples of virtual I2C devices for Platform or Framework features not available on the REV Hubs:

• PlatformSPI
• PlatformDAC
• PlatformMIPI
• PlatformCANBus
• PlatformEncoderPort

Any number of TurboHub instances, running on any number of Platforms, can be connected to a REV Control Hub or to an Android phone.

The TurboHUB virtual device is intended to:

• Serve as proof of concept of the DIY-MRC,
• Inform the finer architectural details of the Framework,
• Provide concrete solutions, enhancements, and cost savings to Teams, and
• Turbocharge the OpModes, and turbocharge opportunities for creativity.

Turbochargers

Teams can turbocharge their OpModes by distributing the processing and/or I/O over several TurboHUB instances, where each instance may be running on a separate Platform.

Distributing the processing of the OpMode increases performance. It also increases fidelity and responsiveness by reducing or eliminating latencies between:

• Sensor data and OpMode logic, and
• OpMode logic and motor or actuator control.

The following are some "turbochargers" that Teams might develop for the TurboHUB:

• PlatformProc: Performs some sort of processing capability unique to the Platform and returns the results to the OpMode.

• PlatformActuator: Converts a position value from the OpMode to a power value of an actuator. Uses encoders, pots, and/or limit switches connected to the same Platform as the motor or actuator. The main OpMode is not involved in acting on data from the sensors.

• PlatformOdometry: Fuses data from the encoders and any IMUs that are connected to the Platform and streams the result to the OpMode.

• PlatformOmniController: Converts Axial, Lateral, and Yaw values from the OpMode to power values of the drive motors. PlatformOmniController is instantiated on the Platform that the Motor Drivers are connected to. It can use PlatformOdometry for course correction.

• PlatformLocalization: Analyzes video from a camera connected to the Platform and streams localization info to the OpMode.

• PlatformObjectTracker: Streams position, velocity, and trajectory info of an object to the OpMode.

• PlatformData: Streams Platform data such as telemetry to the OpMode.

Important

When turbochargers are instantiated on separate Platforms, processing is performed in parallel with the other turbochargers, and in parallel with the OpMode.